WebAssembly: Wasm::IndexOrName has a raw pointer to Name
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2017-10-31  JF Bastien  <jfbastien@apple.com>
2
3         WebAssembly: Wasm::IndexOrName has a raw pointer to Name
4         https://bugs.webkit.org/show_bug.cgi?id=176644
5
6         Reviewed by Michael Saboff.
7
8         IndexOrName now keeps a RefPtr to its original NameSection, which
9         holds the Name (or references nullptr if Index). Holding onto the
10         entire section seems like the better thing to do, since backtraces
11         probably contain multiple names from the same Module.
12
13         * JavaScriptCore.xcodeproj/project.pbxproj:
14         * interpreter/Interpreter.cpp:
15         (JSC::GetStackTraceFunctor::operator() const):
16         * interpreter/StackVisitor.h: Frame is no longer POD because of the
17         RefPtr.
18         * runtime/StackFrame.cpp:
19         (JSC::StackFrame::StackFrame):
20         * runtime/StackFrame.h: Drop the union, size is now 40 bytes.
21         (JSC::StackFrame::StackFrame): Deleted. Initialized in class instead.
22         (JSC::StackFrame::wasm): Deleted. Make it a ctor instead.
23         * wasm/WasmBBQPlanInlines.h:
24         (JSC::Wasm::BBQPlan::initializeCallees):
25         * wasm/WasmCallee.cpp:
26         (JSC::Wasm::Callee::Callee):
27         * wasm/WasmCallee.h:
28         (JSC::Wasm::Callee::create):
29         * wasm/WasmFormat.h: Move NameSection to its own header.
30         (JSC::Wasm::isValidNameType):
31         (JSC::Wasm::NameSection::get): Deleted.
32         * wasm/WasmIndexOrName.cpp:
33         (JSC::Wasm::IndexOrName::IndexOrName):
34         (JSC::Wasm::makeString):
35         * wasm/WasmIndexOrName.h:
36         (JSC::Wasm::IndexOrName::IndexOrName):
37         (JSC::Wasm::IndexOrName::isEmpty const):
38         (JSC::Wasm::IndexOrName::isIndex const):
39         * wasm/WasmModuleInformation.cpp:
40         (JSC::Wasm::ModuleInformation::ModuleInformation):
41         * wasm/WasmModuleInformation.h:
42         (JSC::Wasm::ModuleInformation::ModuleInformation): Deleted.
43         * wasm/WasmNameSection.h:
44         (JSC::Wasm::NameSection::get):
45         (JSC::Wasm::NameSection::create): Deleted.
46         * wasm/WasmNameSectionParser.cpp:
47         (JSC::Wasm::NameSectionParser::parse):
48         * wasm/WasmNameSectionParser.h:
49         * wasm/WasmOMGPlan.cpp:
50         (JSC::Wasm::OMGPlan::work):
51
52 2017-10-31  Tim Horton  <timothy_horton@apple.com>
53
54         Clean up some drag and drop feature flags
55         https://bugs.webkit.org/show_bug.cgi?id=179082
56
57         Reviewed by Simon Fraser.
58
59         * Configurations/FeatureDefines.xcconfig:
60
61 2017-10-31  Commit Queue  <commit-queue@webkit.org>
62
63         Unreviewed, rolling out r224243, r224246, and r224248.
64         https://bugs.webkit.org/show_bug.cgi?id=179083
65
66         The patch and fix broke the Windows build. (Requested by
67         mlewis13 on #webkit).
68
69         Reverted changesets:
70
71         "StructureStubInfo should have GPRReg members not int8_ts"
72         https://bugs.webkit.org/show_bug.cgi?id=179071
73         https://trac.webkit.org/changeset/224243
74
75         "Make all register enums be backed by uint8_t."
76         https://bugs.webkit.org/show_bug.cgi?id=179074
77         https://trac.webkit.org/changeset/224246
78
79         "Unreviewed, windows build fix."
80         https://trac.webkit.org/changeset/224248
81
82 2017-10-31  Tim Horton  <timothy_horton@apple.com>
83
84         Fix up some content filtering feature flags
85         https://bugs.webkit.org/show_bug.cgi?id=179079
86
87         Reviewed by Simon Fraser.
88
89         * Configurations/FeatureDefines.xcconfig:
90
91 2017-10-31  Keith Miller  <keith_miller@apple.com>
92
93         Unreviewed, windows build fix.
94
95         * assembler/X86Assembler.h:
96         (JSC::X86Assembler::numberOfRegisters):
97         (JSC::X86Assembler::numberOfSPRegisters):
98         (JSC::X86Assembler::numberOfFPRegisters):
99
100 2017-10-31  Keith Miller  <keith_miller@apple.com>
101
102         Make all register enums be backed by uint8_t.
103         https://bugs.webkit.org/show_bug.cgi?id=179074
104
105         Reviewed by Mark Lam.
106
107         * assembler/ARM64Assembler.h:
108         * assembler/ARMAssembler.h:
109         * assembler/ARMv7Assembler.h:
110         * assembler/MIPSAssembler.h:
111         * assembler/MacroAssembler.h:
112         * assembler/X86Assembler.h:
113
114 2017-10-31  Keith Miller  <keith_miller@apple.com>
115
116         StructureStubInfo should have GPRReg members not int8_ts
117         https://bugs.webkit.org/show_bug.cgi?id=179071
118
119         Reviewed by Michael Saboff.
120
121         This patch makes the various RegisterID enums be backed by
122         uint8_t. This means that we can remove the old int8_t members in
123         StructureStubInfo and replace them with the correct enum types.
124
125         Also, this fixes an indentation issue in ARMv7Assembler.h.
126
127         * assembler/ARM64Assembler.h:
128         * assembler/ARMAssembler.h:
129         * assembler/ARMv7Assembler.h:
130         (JSC::ARMRegisters::asSingle):
131         (JSC::ARMRegisters::asDouble):
132         * assembler/MIPSAssembler.h:
133         * assembler/X86Assembler.h:
134         * bytecode/InlineAccess.cpp:
135         (JSC::InlineAccess::generateSelfPropertyAccess):
136         (JSC::getScratchRegister):
137         * bytecode/PolymorphicAccess.cpp:
138         (JSC::PolymorphicAccess::regenerate):
139         * bytecode/StructureStubInfo.h:
140         (JSC::StructureStubInfo::valueRegs const):
141         * dfg/DFGSpeculativeJIT.cpp:
142         (JSC::DFG::SpeculativeJIT::compileIn):
143         * ftl/FTLLowerDFGToB3.cpp:
144         (JSC::FTL::DFG::LowerDFGToB3::compileIn):
145         * jit/JITInlineCacheGenerator.cpp:
146         (JSC::JITByIdGenerator::JITByIdGenerator):
147         (JSC::JITGetByIdWithThisGenerator::JITGetByIdWithThisGenerator):
148
149 2017-10-31  Devin Rousso  <webkit@devinrousso.com>
150
151         Web Inspector: make ScriptCallStack::maxCallStackSizeToCapture the default value when capturing backtraces
152         https://bugs.webkit.org/show_bug.cgi?id=179048
153
154         Reviewed by Mark Lam.
155
156         * inspector/ScriptCallStackFactory.h:
157         * inspector/ScriptCallStackFactory.cpp:
158         (createScriptCallStack):
159         (createScriptCallStackForConsole):
160         (createScriptCallStackFromException):
161
162         * inspector/ConsoleMessage.cpp:
163         (Inspector::ConsoleMessage::autogenerateMetadata):
164         * inspector/JSGlobalObjectInspectorController.cpp:
165         (Inspector::JSGlobalObjectInspectorController::reportAPIException):
166         * inspector/agents/InspectorConsoleAgent.cpp:
167         (Inspector::InspectorConsoleAgent::count):
168         * inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
169         (Inspector::JSGlobalObjectDebuggerAgent::breakpointActionLog):
170
171 2017-10-31  Carlos Garcia Campos  <cgarcia@igalia.com>
172
173         Unreviewed. Fix GTK+ make distcheck.
174
175         Ensure DERIVED_SOURCES_JAVASCRIPTCORE_DIR/yarr is created before scripts generating files there are run.
176
177         * CMakeLists.txt:
178
179 2017-10-30  Saam Barati  <sbarati@apple.com>
180
181         We need a storeStoreFence before storing to the instruction stream's live variable catch data
182         https://bugs.webkit.org/show_bug.cgi?id=178649
183
184         Reviewed by Keith Miller.
185
186         * bytecode/CodeBlock.cpp:
187         (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
188
189 2017-10-30  Michael Catanzaro  <mcatanzaro@igalia.com>
190
191         [WPE] Fix build warnings
192         https://bugs.webkit.org/show_bug.cgi?id=178899
193
194         Reviewed by Carlos Alberto Lopez Perez.
195
196         * PlatformWPE.cmake:
197
198 2017-10-30  Zan Dobersek  <zdobersek@igalia.com>
199
200         [ARMv7] Fix initial start register support in YarrJIT
201         https://bugs.webkit.org/show_bug.cgi?id=178641
202
203         Reviewed by Saam Barati.
204
205         * yarr/YarrJIT.cpp: On ARMv7, use r8 as the initialStart register in the
206         YarrGenerator class. r6 should be avoided since it's already used inside
207         MacroAssemblerARMv7 as addressTempRegister. r7 isn't picked because it
208         can be used as the frame pointer register when targetting ARM Thumb2.
209
210 2017-10-30  Zan Dobersek  <zdobersek@igalia.com>
211
212         [ARM64][Linux] Re-enable Gigacage
213         https://bugs.webkit.org/show_bug.cgi?id=178130
214
215         Reviewed by Michael Catanzaro.
216
217         Guard the current globaladdr opcode implementation for ARM64 with
218         OS(DARWIN) as it's only usable for Mach-O.
219
220         For OS(LINUX), ELF-supported :got: and :got_lo12: relocation specifiers
221         have to be used. The .loh directive can't be used as it's not supported
222         in GCC or the ld linker.
223
224         On every other OS target, a compilation error is thrown.
225
226         * offlineasm/arm64.rb:
227
228 2017-10-27  Devin Rousso  <webkit@devinrousso.com>
229
230         Web Inspector: Canvas Tab: no way to see backtrace of where a canvas context was created
231         https://bugs.webkit.org/show_bug.cgi?id=178799
232         <rdar://problem/35175805>
233
234         Reviewed by Brian Burg.
235
236         * inspector/protocol/Canvas.json:
237         Add optional `backtrace` to Canvas type that is an array of Console.CallFrame.
238
239 2017-10-27  Yusuke Suzuki  <utatane.tea@gmail.com>
240
241         [JSC] Tweak ES6 generator function to allow inlining
242         https://bugs.webkit.org/show_bug.cgi?id=178935
243
244         Reviewed by Saam Barati.
245
246         We optimize builtins' generator helper functions to allow them inlined in the caller side.
247         This patch adjust the layer between @generatorResume, next(), throw(), and return() to allow
248         them inlined in DFG.
249
250                                        baseline                  patched
251
252         spread-generator.es6      301.2637+-11.1011    ^    260.5905+-14.2258       ^ definitely 1.1561x faster
253         generator.es6             269.6030+-13.2435    ^    148.8840+-6.7614        ^ definitely 1.8108x faster
254
255         * builtins/GeneratorPrototype.js:
256         (globalPrivate.generatorResume):
257         (next):
258         (return):
259         (throw):
260
261 2017-10-27  Saam Barati  <sbarati@apple.com>
262
263         Bytecode liveness should live on UnlinkedCodeBlock so it can be shared amongst CodeBlocks
264         https://bugs.webkit.org/show_bug.cgi?id=178949
265
266         Reviewed by Keith Miller.
267
268         This patch stores BytecodeLiveness on UnlinkedCodeBlock instead of CodeBlock
269         so that we don't need to recompute liveness for the same UnlinkedCodeBlock
270         more than once. To do this, this patch solidifies the invariant that CodeBlock
271         linking can't do anything that would change the result of liveness. For example,
272         it can't introduce new locals. This invariant was met my JSC before, because we
273         didn't do anything in bytecode linking that would change liveness. However, it is
274         now a correctness requirement that we don't do anything that would change the
275         result of running liveness. To support this change, I've refactored BytecodeGraph
276         to not be tied to a CodeBlockType*. Things that perform liveness will pass in
277         CodeBlockType* and the instruction stream as needed. This means that we may
278         compute liveness with one CodeBlock*'s instruction stream, and then perform
279         queries on that analysis with a different CodeBlock*'s instruction stream.
280
281         This seems to be a 2% JSBench progression.
282
283         * bytecode/BytecodeGeneratorification.cpp:
284         (JSC::BytecodeGeneratorification::BytecodeGeneratorification):
285         (JSC::BytecodeGeneratorification::graph):
286         (JSC::BytecodeGeneratorification::storageForGeneratorLocal):
287         (JSC::GeneratorLivenessAnalysis::run):
288         (JSC::BytecodeGeneratorification::run):
289         * bytecode/BytecodeGraph.h:
290         (JSC::BytecodeGraph::BytecodeGraph):
291         (JSC::BytecodeGraph::codeBlock const): Deleted.
292         (JSC::BytecodeGraph::instructions): Deleted.
293         (JSC::BytecodeGraph<Block>::BytecodeGraph): Deleted.
294         * bytecode/BytecodeLivenessAnalysis.cpp:
295         (JSC::BytecodeLivenessAnalysis::BytecodeLivenessAnalysis):
296         (JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeOffset):
297         (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
298         (JSC::BytecodeLivenessAnalysis::computeKills):
299         (JSC::BytecodeLivenessAnalysis::dumpResults):
300         (JSC::BytecodeLivenessAnalysis::operandIsLiveAtBytecodeOffset): Deleted.
301         (JSC::BytecodeLivenessAnalysis::compute): Deleted.
302         * bytecode/BytecodeLivenessAnalysis.h:
303         * bytecode/BytecodeLivenessAnalysisInlines.h:
304         (JSC::BytecodeLivenessPropagation::stepOverInstruction):
305         (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBytecodeOffset):
306         (JSC::BytecodeLivenessPropagation::computeLocalLivenessForBlock):
307         (JSC::BytecodeLivenessPropagation::getLivenessInfoAtBytecodeOffset):
308         (JSC::BytecodeLivenessPropagation::runLivenessFixpoint):
309         * bytecode/BytecodeRewriter.cpp:
310         (JSC::BytecodeRewriter::applyModification):
311         (JSC::BytecodeRewriter::execute):
312         (JSC::BytecodeRewriter::adjustJumpTargetsInFragment):
313         * bytecode/BytecodeRewriter.h:
314         (JSC::BytecodeRewriter::BytecodeRewriter):
315         (JSC::BytecodeRewriter::removeBytecode):
316         (JSC::BytecodeRewriter::graph):
317         * bytecode/CodeBlock.cpp:
318         (JSC::CodeBlock::finishCreation):
319         (JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeOffsetSlow):
320         (JSC::CodeBlock::validate):
321         (JSC::CodeBlock::livenessAnalysisSlow): Deleted.
322         * bytecode/CodeBlock.h:
323         (JSC::CodeBlock::livenessAnalysis):
324         * bytecode/UnlinkedCodeBlock.cpp:
325         (JSC::UnlinkedCodeBlock::applyModification):
326         (JSC::UnlinkedCodeBlock::livenessAnalysisSlow):
327         * bytecode/UnlinkedCodeBlock.h:
328         (JSC::UnlinkedCodeBlock::livenessAnalysis):
329         * dfg/DFGGraph.cpp:
330         (JSC::DFG::Graph::livenessFor):
331         (JSC::DFG::Graph::killsFor):
332         * dfg/DFGPlan.cpp:
333         (JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
334         * jit/JIT.cpp:
335         (JSC::JIT::privateCompileMainPass):
336
337 2017-10-27  Keith Miller  <keith_miller@apple.com>
338
339         Add unified source list files and build scripts to Xcode project navigator
340         https://bugs.webkit.org/show_bug.cgi?id=178959
341
342         Reviewed by Andy Estes.
343
344         Also, Add some extra source files for so new .cpp/.mm files don't cause the build
345         to fail right away. We already do this in WebCore.
346
347         * JavaScriptCore.xcodeproj/project.pbxproj:
348         * PlatformMac.cmake:
349         * SourcesCocoa.txt: Renamed from Source/JavaScriptCore/SourcesMac.txt.
350
351 2017-10-27  JF Bastien  <jfbastien@apple.com>
352
353         WebAssembly: update arbitrary limits to what browsers use
354         https://bugs.webkit.org/show_bug.cgi?id=178946
355         <rdar://problem/34257412>
356         <rdar://problem/34501154>
357
358         Reviewed by Saam Barati.
359
360         https://github.com/WebAssembly/design/issues/1138 discusses the
361         arbitrary function size limit, which it turns out Chrome and
362         Firefox didn't enforce. We didn't use it because it was
363         ridiculously low and actual programs ran into that limit (bummer
364         for Edge which just shipped it...). Now that we agree on a high
365         arbitrary program limit, let's update it! While I'm doing this
366         there are a few other spots that I polished to use Checked or
367         better check limits overall.
368
369         * wasm/WasmB3IRGenerator.cpp:
370         (JSC::Wasm::B3IRGenerator::addLocal):
371         * wasm/WasmFormat.cpp:
372         (JSC::Wasm::Segment::create):
373         * wasm/WasmFunctionParser.h:
374         (JSC::Wasm::FunctionParser<Context>::parse):
375         * wasm/WasmInstance.cpp:
376         * wasm/WasmLimits.h:
377         * wasm/WasmModuleParser.cpp:
378         (JSC::Wasm::ModuleParser::parseGlobal):
379         (JSC::Wasm::ModuleParser::parseCode):
380         (JSC::Wasm::ModuleParser::parseData):
381         * wasm/WasmSignature.h:
382         (JSC::Wasm::Signature::allocatedSize):
383         * wasm/WasmTable.cpp:
384         (JSC::Wasm::Table::Table):
385         * wasm/js/JSWebAssemblyTable.cpp:
386         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
387         (JSC::JSWebAssemblyTable::grow):
388
389 2017-10-26  Michael Saboff  <msaboff@apple.com>
390
391         REGRESSION(r222601): We fail to properly backtrack into a sub pattern of a parenthesis with non-zero minimum
392         https://bugs.webkit.org/show_bug.cgi?id=178890
393
394         Reviewed by Keith Miller.
395
396         We need to let a contained subpattern backtrack before declaring that the containing
397         parenthesis doesn't match.  If the subpattern fails to match backtracking, then we
398         can check to see if we trying to backtrack below the minimum match count.
399         
400         * yarr/YarrInterpreter.cpp:
401         (JSC::Yarr::Interpreter::backtrackParentheses):
402
403 2017-10-26  Mark Lam  <mark.lam@apple.com>
404
405         JSRopeString::RopeBuilder::append() should check for overflows.
406         https://bugs.webkit.org/show_bug.cgi?id=178385
407         <rdar://problem/35027468>
408
409         Reviewed by Saam Barati.
410
411         1. Made RopeString check for overflow like the Checked class does.
412         2. Added a missing overflow check in objectProtoFuncToString().
413
414         * runtime/JSString.cpp:
415         (JSC::JSRopeString::RopeBuilder<RecordOverflow>::expand):
416         (JSC::JSRopeString::RopeBuilder::expand): Deleted.
417         * runtime/JSString.h:
418         * runtime/ObjectPrototype.cpp:
419         (JSC::objectProtoFuncToString):
420         * runtime/Operations.h:
421         (JSC::jsStringFromRegisterArray):
422         (JSC::jsStringFromArguments):
423
424 2017-10-26  JF Bastien  <jfbastien@apple.com>
425
426         WebAssembly: no VM / JS version of our implementation
427         https://bugs.webkit.org/show_bug.cgi?id=177472
428
429         Reviewed by Michael Saboff.
430
431         This patch removes all appearances of "JS" and "VM" in the wasm
432         directory. These now only appear in the wasm/js directory, which
433         is only used in a JS embedding of wasm. It should therefore now be
434         possible to create non-JS embeddings of wasm through JSC, though
435         it'll still require:
436
437           - Mild codegen for wasm<->embedder calls;
438           - A strategy for trap handling (no need for full unwind! Could kill).
439           - Creation of the Wasm::* objects.
440           - Calling convention handling to call the embedder.
441           - Handling of multiple embedders (see #177475, this is optional).
442
443         Most of the patch consists in renaming JSWebAssemblyInstance to
444         Instance, and removing temporary copies which I'd added to make
445         this specific patch very simple.
446
447         * interpreter/CallFrame.cpp:
448         (JSC::CallFrame::wasmAwareLexicalGlobalObject): this one place
449         which needs to know about who "owns" the Wasm::Instance. In a JS
450         embedding it's the JSWebAssemblyInstance.
451         * wasm/WasmB3IRGenerator.cpp:
452         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
453         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
454         (JSC::Wasm::B3IRGenerator::addGrowMemory):
455         (JSC::Wasm::B3IRGenerator::addCurrentMemory):
456         (JSC::Wasm::B3IRGenerator::getGlobal):
457         (JSC::Wasm::B3IRGenerator::setGlobal):
458         (JSC::Wasm::B3IRGenerator::addCall):
459         (JSC::Wasm::B3IRGenerator::addCallIndirect):
460         * wasm/WasmBinding.cpp:
461         (JSC::Wasm::wasmToWasm):
462         * wasm/WasmContext.cpp:
463         (JSC::Wasm::Context::load const):
464         (JSC::Wasm::Context::store):
465         * wasm/WasmContext.h:
466         * wasm/WasmEmbedder.h:
467         * wasm/WasmInstance.cpp:
468         (JSC::Wasm::Instance::Instance):
469         (JSC::Wasm::Instance::create):
470         (JSC::Wasm::Instance::extraMemoryAllocated const):
471         * wasm/WasmInstance.h: add an "owner", the Wasm::Context, move the
472         "tail" import information from JSWebAssemblyInstance over to here.
473         (JSC::Wasm::Instance::finalizeCreation):
474         (JSC::Wasm::Instance::owner const):
475         (JSC::Wasm::Instance::offsetOfOwner):
476         (JSC::Wasm::Instance::context const):
477         (JSC::Wasm::Instance::setMemory):
478         (JSC::Wasm::Instance::setTable):
479         (JSC::Wasm::Instance::offsetOfMemory):
480         (JSC::Wasm::Instance::offsetOfGlobals):
481         (JSC::Wasm::Instance::offsetOfTable):
482         (JSC::Wasm::Instance::offsetOfTail):
483         (JSC::Wasm::Instance::numImportFunctions const):
484         (JSC::Wasm::Instance::importFunctionInfo):
485         (JSC::Wasm::Instance::offsetOfTargetInstance):
486         (JSC::Wasm::Instance::offsetOfWasmEntrypoint):
487         (JSC::Wasm::Instance::offsetOfWasmToEmbedderStubExecutableAddress):
488         (JSC::Wasm::Instance::offsetOfImportFunction):
489         (JSC::Wasm::Instance::importFunction):
490         (JSC::Wasm::Instance::allocationSize):
491         (JSC::Wasm::Instance::create): Deleted.
492         * wasm/WasmOMGPlan.cpp:
493         (JSC::Wasm::OMGPlan::runForIndex):
494         * wasm/WasmOMGPlan.h:
495         * wasm/WasmTable.cpp:
496         (JSC::Wasm::Table::Table):
497         (JSC::Wasm::Table::setFunction):
498         * wasm/WasmTable.h:
499         * wasm/WasmThunks.cpp:
500         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
501         (JSC::Wasm::triggerOMGTierUpThunkGenerator):
502         * wasm/js/JSToWasm.cpp:
503         (JSC::Wasm::createJSToWasmWrapper):
504         * wasm/js/JSWebAssemblyInstance.cpp: delete code that is now on Wasm::Instance
505         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance): The embedder
506         decides what the import function is. Here we must properly
507         placement-new it to what we've elected (and initialize it later).
508         (JSC::JSWebAssemblyInstance::visitChildren):
509         (JSC::JSWebAssemblyInstance::finalizeCreation):
510         (JSC::JSWebAssemblyInstance::create):
511         * wasm/js/JSWebAssemblyInstance.h: delete code that is now on Wasm::Instance
512         (JSC::JSWebAssemblyInstance::instance):
513         (JSC::JSWebAssemblyInstance::moduleNamespaceObject):
514         (JSC::JSWebAssemblyInstance::setMemory):
515         (JSC::JSWebAssemblyInstance::table):
516         (JSC::JSWebAssemblyInstance::setTable):
517         (JSC::JSWebAssemblyInstance::offsetOfInstance):
518         (JSC::JSWebAssemblyInstance::offsetOfCallee):
519         (JSC::JSWebAssemblyInstance::context const): Deleted.
520         (JSC::JSWebAssemblyInstance::offsetOfTail): Deleted.
521         (): Deleted.
522         (JSC::JSWebAssemblyInstance::importFunctionInfo): Deleted.
523         (JSC::JSWebAssemblyInstance::offsetOfTargetInstance): Deleted.
524         (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint): Deleted.
525         (JSC::JSWebAssemblyInstance::offsetOfWasmToEmbedderStubExecutableAddress): Deleted.
526         (JSC::JSWebAssemblyInstance::offsetOfImportFunction): Deleted.
527         (JSC::JSWebAssemblyInstance::importFunction): Deleted.
528         (JSC::JSWebAssemblyInstance::internalMemory): Deleted.
529         (JSC::JSWebAssemblyInstance::wasmCodeBlock const): Deleted.
530         (JSC::JSWebAssemblyInstance::offsetOfWasmTable): Deleted.
531         (JSC::JSWebAssemblyInstance::offsetOfGlobals): Deleted.
532         (JSC::JSWebAssemblyInstance::offsetOfCodeBlock): Deleted.
533         (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock): Deleted.
534         (JSC::JSWebAssemblyInstance::offsetOfCachedStackLimit): Deleted.
535         (JSC::JSWebAssemblyInstance::offsetOfWasmMemory): Deleted.
536         (JSC::JSWebAssemblyInstance::offsetOfTopEntryFramePointer): Deleted.
537         (JSC::JSWebAssemblyInstance::cachedStackLimit const): Deleted.
538         (JSC::JSWebAssemblyInstance::setCachedStackLimit): Deleted.
539         (JSC::JSWebAssemblyInstance::wasmMemory): Deleted.
540         (JSC::JSWebAssemblyInstance::wasmModule): Deleted.
541         (JSC::JSWebAssemblyInstance::allocationSize): Deleted.
542         * wasm/js/JSWebAssemblyTable.cpp:
543         (JSC::JSWebAssemblyTable::setFunction):
544         * wasm/js/WasmToJS.cpp: One extra indirection to find the JSWebAssemblyInstance.
545         (JSC::Wasm::materializeImportJSCell):
546         (JSC::Wasm::handleBadI64Use):
547         (JSC::Wasm::wasmToJS):
548         (JSC::Wasm::wasmToJSException):
549         * wasm/js/WasmToJS.h:
550         * wasm/js/WebAssemblyFunction.cpp:
551         (JSC::callWebAssemblyFunction):
552         * wasm/js/WebAssemblyInstanceConstructor.cpp:
553         (JSC::constructJSWebAssemblyInstance):
554         * wasm/js/WebAssemblyModuleRecord.cpp:
555         (JSC::WebAssemblyModuleRecord::link):
556         (JSC::WebAssemblyModuleRecord::evaluate):
557         * wasm/js/WebAssemblyPrototype.cpp:
558         (JSC::instantiate):
559         * wasm/js/WebAssemblyWrapperFunction.cpp:
560         (JSC::WebAssemblyWrapperFunction::create):
561
562 2017-10-25  Devin Rousso  <webkit@devinrousso.com>
563
564         Web Inspector: provide a way to enable/disable event listeners
565         https://bugs.webkit.org/show_bug.cgi?id=177451
566         <rdar://problem/34994925>
567
568         Reviewed by Joseph Pecoraro.
569
570         * inspector/protocol/DOM.json:
571         Add `setEventListenerDisabled` command that enables/disables a specific event listener
572         during event dispatch. When a disabled event listener is fired, the listener's callback will
573         not be called.
574
575 2017-10-25  Commit Queue  <commit-queue@webkit.org>
576
577         Unreviewed, rolling out r223691 and r223729.
578         https://bugs.webkit.org/show_bug.cgi?id=178834
579
580         Broke Speedometer 2 React-Redux-TodoMVC test case (Requested
581         by rniwa on #webkit).
582
583         Reverted changesets:
584
585         "Turn recursive tail calls into loops"
586         https://bugs.webkit.org/show_bug.cgi?id=176601
587         https://trac.webkit.org/changeset/223691
588
589         "REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning:
590         comparison is always false due to limited range of data type
591         [-Wtype-limits]"
592         https://bugs.webkit.org/show_bug.cgi?id=178543
593         https://trac.webkit.org/changeset/223729
594
595 2017-10-25  Michael Saboff  <msaboff@apple.com>
596
597         REGRESSION(r223937): Use of -fobjc-weak causes build failures with older compilers
598         https://bugs.webkit.org/show_bug.cgi?id=178825
599
600         Reviewed by Mark Lam.
601
602         Enable ARC for ARM64_32.  This eliminate the need for setting CLANG_ENABLE_OBJC_WEAK.
603
604         * Configurations/ToolExecutable.xcconfig:
605
606 2017-10-25  Keith Miller  <keith_miller@apple.com>
607
608         Fix implicit cast of enum, which seems to break the windows build of unified sources.
609         https://bugs.webkit.org/show_bug.cgi?id=178822
610
611         Reviewed by Saam Barati.
612
613         * bytecode/DFGExitProfile.h:
614         (JSC::DFG::FrequentExitSite::hash const):
615
616 2017-10-24  Michael Saboff  <msaboff@apple.com>
617
618         Allow OjbC Weak References when building TestAPI
619         https://bugs.webkit.org/show_bug.cgi?id=178748
620
621         Reviewed by Dan Bernstein.
622
623         Set TestAPI build flag Weak References in Manual Retain Release to true.
624
625         * JavaScriptCore.xcodeproj/project.pbxproj: Reverted.
626         * Configurations/ToolExecutable.xcconfig: Changed the flag here instead.
627
628 2017-10-24  Eric Carlson  <eric.carlson@apple.com>
629
630         Web Inspector: Enable WebKit logging configuration and display
631         https://bugs.webkit.org/show_bug.cgi?id=177027
632         <rdar://problem/33964767>
633
634         Reviewed by Joseph Pecoraro.
635
636         * inspector/ConsoleMessage.cpp:
637         (Inspector::messageSourceValue): Inspector::Protocol::Console::ConsoleMessage -> 
638             Inspector::Protocol::Console::ChannelSource.
639         * inspector/agents/JSGlobalObjectConsoleAgent.cpp:
640         (Inspector::JSGlobalObjectConsoleAgent::getLoggingChannels): There are no logging channels
641             specific to a JSContext yet, so return an empty channel array.
642         (Inspector::JSGlobalObjectConsoleAgent::setLoggingChannelLevel): No channels, return an error.
643         * inspector/agents/JSGlobalObjectConsoleAgent.h:
644
645         * inspector/protocol/Console.json: Add ChannelSource, ChannelLevel, and Channel. Add getLoggingChannels
646             and setLoggingChannelLevel.
647
648         * inspector/scripts/codegen/generator.py: Special case "webrtc"-> "WebRTC".
649         * inspector/scripts/tests/generic/expected/enum-values.json-result:
650         * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
651         * inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
652         * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
653         * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
654
655         * runtime/ConsoleTypes.h: Add Media and WebRTC.
656
657 2017-10-24  Michael Saboff  <msaboff@apple.com>
658
659         Allow OjbC Weak References when building TestAPI
660         https://bugs.webkit.org/show_bug.cgi?id=178748
661
662         Reviewed by Saam Barati.
663
664         Set TestAPI build flag Weak References in Manual Retain Release to true.
665
666         * JavaScriptCore.xcodeproj/project.pbxproj:
667
668 2017-10-24  Yusuke Suzuki  <utatane.tea@gmail.com>
669
670         [FTL] Support NewStringObject
671         https://bugs.webkit.org/show_bug.cgi?id=178737
672
673         Reviewed by Saam Barati.
674
675         FTL should support NewStringObject and encourage use of NewStringObject in DFG pipeline.
676         After this change, we can convert `CallObjectConstructor(String)` to `NewStringObject(String)`.
677
678         * ftl/FTLAbstractHeapRepository.h:
679         * ftl/FTLCapabilities.cpp:
680         (JSC::FTL::canCompile):
681         * ftl/FTLLowerDFGToB3.cpp:
682         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
683         (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject):
684
685 2017-10-24  Guillaume Emont  <guijemont@igalia.com>
686
687         [mips] fix offsets of branches that have to go over a jump
688         https://bugs.webkit.org/show_bug.cgi?id=153464
689
690         The jump() function creates 8 instructions, but the offsets of branches
691         meant to go over them only account for 6. In most cases, this is not an
692         issue as the last two instructions of jump() would be nops, but in the
693         rarer case where the jump destination is in a different 256 MB segment,
694         MIPSAssembler::linkWithOffset() will rewrite the code in a way in which
695         the last 4 instructions would be a 2 instruction load (lui/ori) into
696         $t9, a "j $t9" and then a nop. The wrong offset will mean that the
697         previous branches meant to go over the whole jump will branch to the
698         "j $t9" instruction, which would jump to whatever is currently in $t9
699         (since lui/ori would not be executed).
700
701         Reviewed by Michael Catanzaro.
702
703         * assembler/MacroAssemblerMIPS.h:
704         (JSC::MacroAssemblerMIPS::branchAdd32):
705         (JSC::MacroAssemblerMIPS::branchMul32):
706         (JSC::MacroAssemblerMIPS::branchSub32):
707         Fix the offsets of branches meant to go over code generated by jump().
708
709 2017-10-24  JF Bastien  <jfbastien@apple.com>
710
711         WebAssembly: NFC renames of things that aren't JS-specific
712         https://bugs.webkit.org/show_bug.cgi?id=178738
713
714         Reviewed by Saam Barati.
715
716         * wasm/WasmB3IRGenerator.cpp:
717         (JSC::Wasm::parseAndCompile):
718         * wasm/WasmB3IRGenerator.h:
719         * wasm/WasmBBQPlan.cpp:
720         (JSC::Wasm::BBQPlan::complete):
721         * wasm/WasmCodeBlock.cpp:
722         (JSC::Wasm::CodeBlock::CodeBlock):
723         * wasm/WasmCodeBlock.h:
724         (JSC::Wasm::CodeBlock::embedderEntrypointCalleeFromFunctionIndexSpace):
725         (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): Deleted.
726         * wasm/WasmFormat.h:
727         * wasm/js/JSToWasm.cpp:
728         (JSC::Wasm::createJSToWasmWrapper):
729         * wasm/js/WebAssemblyModuleRecord.cpp:
730         (JSC::WebAssemblyModuleRecord::link):
731         (JSC::WebAssemblyModuleRecord::evaluate):
732
733 2017-10-24  Stephan Szabo  <stephan.szabo@sony.com>
734
735         [Win][JSCOnly] Make jsconly build testapi and dlls and copy dlls when running tests
736         https://bugs.webkit.org/show_bug.cgi?id=177279
737
738         Reviewed by Yusuke Suzuki.
739
740         * shell/PlatformJSCOnly.cmake: Added.
741
742 2017-10-15  Yusuke Suzuki  <utatane.tea@gmail.com>
743
744         [JSC] modules can be visited more than once when resolving bindings through "star" exports as long as the exportName is different each time
745         https://bugs.webkit.org/show_bug.cgi?id=178308
746
747         Reviewed by Mark Lam.
748
749         With the change of the spec[1], we now do not need to remember star resolution modules.
750         We reflect this change to our implementation. Since this change is covered by test262,
751         this patch improves the score of test262.
752
753         We also add logging to ResolveExport to debug it easily.
754
755         [1]: https://github.com/tc39/ecma262/commit/a865e778ff0fc60e26e3e1c589635103710766a1
756
757         * runtime/AbstractModuleRecord.cpp:
758         (JSC::AbstractModuleRecord::ResolveQuery::dump const):
759         (JSC::AbstractModuleRecord::resolveExportImpl):
760
761 2017-10-24  Yusuke Suzuki  <utatane.tea@gmail.com>
762
763         [JSC] Use emitDumbVirtualCall in 32bit JIT
764         https://bugs.webkit.org/show_bug.cgi?id=178644
765
766         Reviewed by Mark Lam.
767
768         This patch aligns 32bit JIT op_call_eval slow case to 64bit version by using emitDumbVirtualCall.
769
770         * jit/JITCall32_64.cpp:
771         (JSC::JIT::compileCallEvalSlowCase):
772
773 2017-10-22  Yusuke Suzuki  <utatane.tea@gmail.com>
774
775         [JSC] Drop ArityCheckData
776         https://bugs.webkit.org/show_bug.cgi?id=178648
777
778         Reviewed by Mark Lam.
779
780         ArityCheckData is used to return a pair of `slotsToAdd` and `thunkToCall`.
781         However, use of `thunkToCall` is removed in 64bit environment at r189575.
782
783         We remove `thunkToCall` and align 32bit implementation to 64bit implementation.
784         Since we no longer need to have the above pair, we can remove ArityCheckData too.
785
786         * llint/LowLevelInterpreter32_64.asm:
787         * llint/LowLevelInterpreter64.asm:
788         * runtime/CommonSlowPaths.cpp:
789         (JSC::SLOW_PATH_DECL):
790         (JSC::setupArityCheckData): Deleted.
791         * runtime/CommonSlowPaths.h:
792         * runtime/VM.cpp:
793         (JSC::VM::VM):
794         * runtime/VM.h:
795
796 2017-10-23  Keith Miller  <keith_miller@apple.com>
797
798         Unreviewed, reland r223866
799
800         Didn't break the windows build...
801
802         Restored changeset:
803
804         "WebAssembly: topEntryFrame on Wasm::Instance"
805         https://bugs.webkit.org/show_bug.cgi?id=178690
806         https://trac.webkit.org/changeset/223866
807
808
809 2017-10-23  Commit Queue  <commit-queue@webkit.org>
810
811         Unreviewed, rolling out r223866.
812         https://bugs.webkit.org/show_bug.cgi?id=178699
813
814         Probably broke the windows build (Requested by keith_miller on
815         #webkit).
816
817         Reverted changeset:
818
819         "WebAssembly: topEntryFrame on Wasm::Instance"
820         https://bugs.webkit.org/show_bug.cgi?id=178690
821         https://trac.webkit.org/changeset/223866
822
823 2017-10-23  Joseph Pecoraro  <pecoraro@apple.com>
824
825         Web Inspector: Remove unused Console.setMonitoringXHREnabled
826         https://bugs.webkit.org/show_bug.cgi?id=178617
827
828         Reviewed by Sam Weinig.
829
830         * JavaScriptCore.xcodeproj/project.pbxproj:
831         * Sources.txt:
832         * inspector/agents/InspectorConsoleAgent.h:
833         * inspector/agents/JSGlobalObjectConsoleAgent.cpp: Removed.
834         * inspector/agents/JSGlobalObjectConsoleAgent.h: Removed.
835         * inspector/protocol/Console.json:
836         Removed files and method.
837
838         * inspector/JSGlobalObjectInspectorController.cpp:
839         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
840         This can use the base ConsoleAgent now.
841
842 2017-10-23  JF Bastien  <jfbastien@apple.com>
843
844         WebAssembly: topEntryFrame on Wasm::Instance
845         https://bugs.webkit.org/show_bug.cgi?id=178690
846
847         Reviewed by Saam Barati.
848
849         topEntryFrame is usually on VM, but for a no-VM WebAssembly we
850         need to hold topEntryFrame elsewhere, and generated code cannot
851         hard-code where topEntryFrame live. Do this at creation time of
852         Wasm::Instance, and then generated code will just load from
853         wherever Wasm::Instance was told topEntryFrame is. In a JavaScript
854         embedding this is still from VM, so all of the unwinding machinery
855         stays the same.
856
857         * dfg/DFGOSREntry.cpp:
858         (JSC::DFG::prepareOSREntry):
859         * dfg/DFGOSRExit.cpp:
860         (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
861         (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
862         * ftl/FTLOSRExitCompiler.cpp:
863         (JSC::FTL::compileStub):
864         * interpreter/Interpreter.cpp:
865         (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
866         * jit/AssemblyHelpers.cpp:
867         (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
868         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
869         * jit/AssemblyHelpers.h:
870         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer):
871         The default parameter was never non-defaulted from any of the
872         callers. The new version calls the impl directly because it
873         doesn't have VM and doesn't hard-code the address of
874         topEntryFrame.
875         * jit/RegisterSet.cpp:
876         (JSC::RegisterSet::vmCalleeSaveRegisterOffsets): This was weird on
877         VM because it's not really VM-specific.
878         * jit/RegisterSet.h:
879         * runtime/VM.cpp:
880         (JSC::VM::getAllCalleeSaveRegisterOffsets): Deleted.
881         * runtime/VM.h:
882         (JSC::VM::getCTIStub):
883         * wasm/WasmB3IRGenerator.cpp:
884         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
885         (JSC::Wasm::B3IRGenerator::addCall):
886         (JSC::Wasm::B3IRGenerator::addCallIndirect):
887         * wasm/WasmInstance.cpp:
888         (JSC::Wasm::Instance::Instance):
889         * wasm/WasmInstance.h: topEntryFramePointer will eventually live
890         here for real. Right now it's mirrored in JSWebAssemblyInstance
891         because that's the acting Context.
892         (JSC::Wasm::Instance::create):
893         (JSC::Wasm::Instance::offsetOfTopEntryFramePointer):
894         * wasm/WasmThunks.cpp:
895         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
896         * wasm/js/JSWebAssemblyInstance.cpp:
897         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
898         * wasm/js/JSWebAssemblyInstance.h: Mirror Wasm::Instance temporarily.
899         (JSC::JSWebAssemblyInstance::offsetOfCallee):
900         (JSC::JSWebAssemblyInstance::offsetOfTopEntryFramePointer):
901         (JSC::JSWebAssemblyInstance::offsetOfVM): Deleted.
902         * wasm/js/WebAssemblyInstanceConstructor.cpp:
903         (JSC::constructJSWebAssemblyInstance):
904         * wasm/js/WebAssemblyPrototype.cpp:
905         (JSC::instantiate):
906
907 2017-10-23  Joseph Pecoraro  <pecoraro@apple.com>
908
909         Web Inspector: Please support HAR Export for network traffic
910         https://bugs.webkit.org/show_bug.cgi?id=146692
911         <rdar://problem/7463672>
912
913         Reviewed by Brian Burg.
914
915         * inspector/protocol/Network.json:
916         Add a walltime to each send request.
917
918 2017-10-23  Matt Lewis  <jlewis3@apple.com>
919
920         Unreviewed, rolling out r223820.
921
922         This caused a build break on Windows.
923
924         Reverted changeset:
925
926         "Web Inspector: Remove unused Console.setMonitoringXHREnabled"
927         https://bugs.webkit.org/show_bug.cgi?id=178617
928         https://trac.webkit.org/changeset/223820
929
930 2017-10-23  Yusuke Suzuki  <utatane.tea@gmail.com>
931
932         [JSC] Use fastJoin in Array#toString
933         https://bugs.webkit.org/show_bug.cgi?id=178062
934
935         Reviewed by Darin Adler.
936
937         Array#toString()'s fast path uses original join operation.
938         But this should use fastJoin if possible.
939         This patch adds a fast path using fastJoin in Array#toString.
940         And we also extend fastJoin to perform fast joining for int32
941         arrays.
942
943                                              baseline                  patched
944
945         double-array-to-string          126.6157+-5.8625     ^    103.7343+-4.4968        ^ definitely 1.2206x faster
946         int32-array-to-string            64.7792+-2.6524           61.2390+-2.1749          might be 1.0578x faster
947         contiguous-array-to-string       62.6224+-2.6388     ^     56.9899+-2.0852        ^ definitely 1.0988x faster
948
949
950         * runtime/ArrayPrototype.cpp:
951         (JSC::fastJoin):
952         (JSC::arrayProtoFuncToString):
953         (JSC::arrayProtoFuncToLocaleString):
954         * runtime/JSStringJoiner.h:
955         (JSC::JSStringJoiner::appendWithoutSideEffects):
956         (JSC::JSStringJoiner::appendInt32):
957         (JSC::JSStringJoiner::appendDouble):
958
959 2017-10-22  Zan Dobersek  <zdobersek@igalia.com>
960
961         [JSC] Remove !(OS(LINUX) && CPU(ARM64)) guards in RegisterState.h
962         https://bugs.webkit.org/show_bug.cgi?id=178452
963
964         Reviewed by Yusuke Suzuki.
965
966         * heap/RegisterState.h: Re-enable the custom RegisterState and
967         ALLOCATE_AND_GET_REGISTER_STATE definitions on ARM64 Linux. These don't
968         cause any crashes nowadays.
969
970 2017-10-22  Yusuke Suzuki  <utatane.tea@gmail.com>
971
972         [JSC][Baseline] Use linkAllSlowCasesForBytecodeOffset as much as possible to simplify slow cases handling
973         https://bugs.webkit.org/show_bug.cgi?id=178647
974
975         Reviewed by Saam Barati.
976
977         There is much code counting slow cases in fast paths to call `linkSlowCase` carefully. This is really error-prone
978         since the number of slow cases depends on values of instruction's metadata. We have linkAllSlowCasesForBytecodeOffset,
979         which drains all slow cases for a specified bytecode offset. In typical cases like just calling a slow path function,
980         this is enough. We use linkAllSlowCasesForBytecodeOffset as much as possible. It significantly simplifies the code.
981
982         * jit/JIT.h:
983         (JSC::JIT::linkAllSlowCases):
984         * jit/JITArithmetic.cpp:
985         (JSC::JIT::emitSlow_op_unsigned):
986         (JSC::JIT::emit_compareAndJump):
987         (JSC::JIT::emit_compareAndJumpSlow):
988         (JSC::JIT::emitSlow_op_inc):
989         (JSC::JIT::emitSlow_op_dec):
990         (JSC::JIT::emitSlow_op_mod):
991         (JSC::JIT::emitSlow_op_negate):
992         (JSC::JIT::emitSlow_op_bitand):
993         (JSC::JIT::emitSlow_op_bitor):
994         (JSC::JIT::emitSlow_op_bitxor):
995         (JSC::JIT::emitSlow_op_lshift):
996         (JSC::JIT::emitSlow_op_rshift):
997         (JSC::JIT::emitSlow_op_urshift):
998         (JSC::JIT::emitSlow_op_add):
999         (JSC::JIT::emitSlow_op_div):
1000         (JSC::JIT::emitSlow_op_mul):
1001         (JSC::JIT::emitSlow_op_sub):
1002         * jit/JITArithmetic32_64.cpp:
1003         (JSC::JIT::emit_compareAndJumpSlow):
1004         (JSC::JIT::emitSlow_op_unsigned):
1005         (JSC::JIT::emitSlow_op_inc):
1006         (JSC::JIT::emitSlow_op_dec):
1007         (JSC::JIT::emitSlow_op_mod):
1008         * jit/JITCall.cpp:
1009         (JSC::JIT::compileCallEvalSlowCase):
1010         (JSC::JIT::compileOpCallSlowCase):
1011         * jit/JITCall32_64.cpp:
1012         (JSC::JIT::compileCallEvalSlowCase):
1013         (JSC::JIT::compileOpCallSlowCase):
1014         * jit/JITInlines.h:
1015         (JSC::JIT::linkAllSlowCasesForBytecodeOffset):
1016         * jit/JITOpcodes.cpp:
1017         (JSC::JIT::emitSlow_op_new_object):
1018         (JSC::JIT::emitSlow_op_create_this):
1019         (JSC::JIT::emitSlow_op_check_tdz):
1020         (JSC::JIT::emitSlow_op_to_this):
1021         (JSC::JIT::emitSlow_op_to_primitive):
1022         (JSC::JIT::emitSlow_op_not):
1023         (JSC::JIT::emitSlow_op_eq):
1024         (JSC::JIT::emitSlow_op_neq):
1025         (JSC::JIT::emitSlow_op_stricteq):
1026         (JSC::JIT::emitSlow_op_nstricteq):
1027         (JSC::JIT::emitSlow_op_instanceof):
1028         (JSC::JIT::emitSlow_op_instanceof_custom):
1029         (JSC::JIT::emitSlow_op_to_number):
1030         (JSC::JIT::emitSlow_op_to_string):
1031         (JSC::JIT::emitSlow_op_loop_hint):
1032         (JSC::JIT::emitSlow_op_check_traps):
1033         (JSC::JIT::emitSlow_op_has_indexed_property):
1034         (JSC::JIT::emitSlow_op_get_direct_pname):
1035         (JSC::JIT::emitSlow_op_has_structure_property):
1036         * jit/JITOpcodes32_64.cpp:
1037         (JSC::JIT::emitSlow_op_new_object):
1038         (JSC::JIT::emitSlow_op_instanceof):
1039         (JSC::JIT::emitSlow_op_instanceof_custom):
1040         (JSC::JIT::emitSlow_op_to_primitive):
1041         (JSC::JIT::emitSlow_op_not):
1042         (JSC::JIT::emitSlow_op_stricteq):
1043         (JSC::JIT::emitSlow_op_nstricteq):
1044         (JSC::JIT::emitSlow_op_to_number):
1045         (JSC::JIT::emitSlow_op_to_string):
1046         (JSC::JIT::emitSlow_op_create_this):
1047         (JSC::JIT::emitSlow_op_to_this):
1048         (JSC::JIT::emitSlow_op_check_tdz):
1049         (JSC::JIT::emitSlow_op_has_indexed_property):
1050         (JSC::JIT::emitSlow_op_get_direct_pname):
1051         * jit/JITPropertyAccess.cpp:
1052         (JSC::JIT::emitSlow_op_try_get_by_id):
1053         (JSC::JIT::emitSlow_op_get_by_id):
1054         (JSC::JIT::emitSlow_op_get_by_id_with_this):
1055         (JSC::JIT::emitSlow_op_put_by_id):
1056         (JSC::JIT::emitSlow_op_resolve_scope):
1057         (JSC::JIT::emitSlow_op_get_from_scope):
1058         (JSC::JIT::emitSlow_op_put_to_scope):
1059         * jit/JITPropertyAccess32_64.cpp:
1060         (JSC::JIT::emitSlow_op_try_get_by_id):
1061         (JSC::JIT::emitSlow_op_get_by_id):
1062         (JSC::JIT::emitSlow_op_get_by_id_with_this):
1063         (JSC::JIT::emitSlow_op_put_by_id):
1064         (JSC::JIT::emitSlow_op_resolve_scope):
1065         (JSC::JIT::emitSlow_op_get_from_scope):
1066         (JSC::JIT::emitSlow_op_put_to_scope):
1067
1068 2017-10-22  Yusuke Suzuki  <utatane.tea@gmail.com>
1069
1070         [JSC] Clean up baseline slow path
1071         https://bugs.webkit.org/show_bug.cgi?id=178646
1072
1073         Reviewed by Saam Barati.
1074
1075         If the given op is just calling a slow path function, we should use DEFINE_SLOW_OP instead.
1076         It is good since (1) we can reduce the manual emitting code and (2) it can clarify which
1077         function is implemented as a slow path call. This patch is an attempt to reduce 32bit specific
1078         code in baseline JIT.
1079
1080         * jit/JIT.cpp:
1081         (JSC::JIT::privateCompileMainPass):
1082         * jit/JIT.h:
1083         * jit/JITArithmetic.cpp:
1084         (JSC::JIT::emit_op_pow): Deleted.
1085         * jit/JITArithmetic32_64.cpp:
1086         (JSC::JIT::emitSlow_op_mod):
1087         * jit/JITOpcodes.cpp:
1088         (JSC::JIT::emit_op_strcat): Deleted.
1089         (JSC::JIT::emit_op_push_with_scope): Deleted.
1090         (JSC::JIT::emit_op_assert): Deleted.
1091         (JSC::JIT::emit_op_create_lexical_environment): Deleted.
1092         (JSC::JIT::emit_op_throw_static_error): Deleted.
1093         (JSC::JIT::emit_op_new_array_with_spread): Deleted.
1094         (JSC::JIT::emit_op_spread): Deleted.
1095         (JSC::JIT::emit_op_get_enumerable_length): Deleted.
1096         (JSC::JIT::emit_op_has_generic_property): Deleted.
1097         (JSC::JIT::emit_op_get_property_enumerator): Deleted.
1098         (JSC::JIT::emit_op_to_index_string): Deleted.
1099         (JSC::JIT::emit_op_create_direct_arguments): Deleted.
1100         (JSC::JIT::emit_op_create_scoped_arguments): Deleted.
1101         (JSC::JIT::emit_op_create_cloned_arguments): Deleted.
1102         (JSC::JIT::emit_op_create_rest): Deleted.
1103         (JSC::JIT::emit_op_unreachable): Deleted.
1104         * jit/JITOpcodes32_64.cpp:
1105         (JSC::JIT::emit_op_strcat): Deleted.
1106         (JSC::JIT::emit_op_push_with_scope): Deleted.
1107         (JSC::JIT::emit_op_assert): Deleted.
1108         (JSC::JIT::emit_op_create_lexical_environment): Deleted.
1109         * jit/JITPropertyAccess.cpp:
1110         (JSC::JIT::emit_op_put_by_val_with_this): Deleted.
1111         (JSC::JIT::emit_op_get_by_val_with_this): Deleted.
1112         (JSC::JIT::emit_op_put_by_id_with_this): Deleted.
1113         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): Deleted.
1114         (JSC::JIT::emit_op_define_data_property): Deleted.
1115         (JSC::JIT::emit_op_define_accessor_property): Deleted.
1116         * jit/JITPropertyAccess32_64.cpp:
1117         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): Deleted.
1118         (JSC::JIT::emit_op_get_by_val_with_this): Deleted.
1119         (JSC::JIT::emit_op_put_by_id_with_this): Deleted.
1120         (JSC::JIT::emit_op_put_by_val_with_this): Deleted.
1121
1122 2017-10-21  Joseph Pecoraro  <pecoraro@apple.com>
1123
1124         Web Inspector: Remove unused Console.setMonitoringXHREnabled
1125         https://bugs.webkit.org/show_bug.cgi?id=178617
1126
1127         Reviewed by Sam Weinig.
1128
1129         * JavaScriptCore.xcodeproj/project.pbxproj:
1130         * Sources.txt:
1131         * inspector/agents/InspectorConsoleAgent.h:
1132         * inspector/agents/JSGlobalObjectConsoleAgent.cpp: Removed.
1133         * inspector/agents/JSGlobalObjectConsoleAgent.h: Removed.
1134         * inspector/protocol/Console.json:
1135         Removed files and method.
1136
1137         * inspector/JSGlobalObjectInspectorController.cpp:
1138         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1139         This can use the base ConsoleAgent now.
1140
1141 2017-10-21  Yusuke Suzuki  <utatane.tea@gmail.com>
1142
1143         [JSC] Remove per-host-function CTI stub in 32bit environment
1144         https://bugs.webkit.org/show_bug.cgi?id=178581
1145
1146         Reviewed by Saam Barati.
1147
1148         JIT::privateCompileCTINativeCall only exists in 32bit environment and it is almost the same to native call CTI stub.
1149         The only difference is that it embed the address of the host function directly in the generated stub. This means
1150         that we have per-host-function CTI stub only in 32bit environment.
1151
1152         This patch just removes it and use one CTI stub instead. This design is the same to the current 64bit implementation.
1153
1154         * jit/JIT.cpp:
1155         (JSC::JIT::compileCTINativeCall): Deleted.
1156         * jit/JIT.h:
1157         * jit/JITOpcodes.cpp:
1158         (JSC::JIT::privateCompileCTINativeCall): Deleted.
1159         * jit/JITOpcodes32_64.cpp:
1160         (JSC::JIT::privateCompileCTINativeCall): Deleted.
1161         * jit/JITThunks.cpp:
1162         (JSC::JITThunks::hostFunctionStub):
1163
1164 2017-10-20  Antoine Quint  <graouts@apple.com>
1165
1166         [Web Animations] Provide basic timeline and animation interfaces
1167         https://bugs.webkit.org/show_bug.cgi?id=178526
1168
1169         Reviewed by Dean Jackson.
1170
1171         Remove the WEB_ANIMATIONS compile-time flag.
1172
1173         * Configurations/FeatureDefines.xcconfig:
1174
1175 2017-10-20  Commit Queue  <commit-queue@webkit.org>
1176
1177         Unreviewed, rolling out r223744, r223750, and r223751.
1178         https://bugs.webkit.org/show_bug.cgi?id=178594
1179
1180         These caused consistent failures in test that existed and were
1181         added in the patches. (Requested by mlewis13 on #webkit).
1182
1183         Reverted changesets:
1184
1185         "[JSC] ScriptFetcher should be notified directly from module
1186         pipeline"
1187         https://bugs.webkit.org/show_bug.cgi?id=178340
1188         https://trac.webkit.org/changeset/223744
1189
1190         "Unreviewed, fix changed line number in test expect files"
1191         https://bugs.webkit.org/show_bug.cgi?id=178340
1192         https://trac.webkit.org/changeset/223750
1193
1194         "Unreviewed, follow up to reflect comments"
1195         https://bugs.webkit.org/show_bug.cgi?id=178340
1196         https://trac.webkit.org/changeset/223751
1197
1198 2017-10-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1199
1200         Unreviewed, follow up to reflect comments
1201         https://bugs.webkit.org/show_bug.cgi?id=178340
1202
1203         * runtime/JSModuleLoader.cpp:
1204         (JSC::JSModuleLoader::notifyCompleted):
1205
1206 2017-10-20  Saam Barati  <sbarati@apple.com>
1207
1208         Optimize accesses to how we get the direct prototype
1209         https://bugs.webkit.org/show_bug.cgi?id=178548
1210
1211         Reviewed by Yusuke Suzuki.
1212
1213         This patch makes JSObject::getPrototypeDirect take VM& as a parameter
1214         so it can use the faster version of the structure accessor function.
1215         The reason for making this change is that JSObjet::getPrototypeDirect
1216         is called on the hot path in property lookup.
1217
1218         * API/JSObjectRef.cpp:
1219         (JSObjectGetPrototype):
1220         * jsc.cpp:
1221         (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
1222         (WTF::DOMJITGetterBaseJSObject::customGetter):
1223         (functionCreateProxy):
1224         * runtime/ArrayPrototype.cpp:
1225         (JSC::speciesWatchpointIsValid):
1226         * runtime/ErrorInstance.cpp:
1227         (JSC::ErrorInstance::sanitizedToString):
1228         * runtime/JSArray.cpp:
1229         (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
1230         * runtime/JSGlobalObject.cpp:
1231         (JSC::JSGlobalObject::init):
1232         (JSC::lastInPrototypeChain):
1233         (JSC::JSGlobalObject::resetPrototype):
1234         (JSC::JSGlobalObject::finishCreation):
1235         * runtime/JSGlobalObjectInlines.h:
1236         (JSC::JSGlobalObject::objectPrototypeIsSane):
1237         (JSC::JSGlobalObject::arrayPrototypeChainIsSane):
1238         (JSC::JSGlobalObject::stringPrototypeChainIsSane):
1239         * runtime/JSLexicalEnvironment.cpp:
1240         (JSC::JSLexicalEnvironment::getOwnPropertySlot):
1241         * runtime/JSMap.cpp:
1242         (JSC::JSMap::isIteratorProtocolFastAndNonObservable):
1243         * runtime/JSObject.cpp:
1244         (JSC::JSObject::calculatedClassName):
1245         (JSC::JSObject::setPrototypeWithCycleCheck):
1246         (JSC::JSObject::getPrototype):
1247         (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
1248         (JSC::JSObject::attemptToInterceptPutByIndexOnHole):
1249         (JSC::JSObject::anyObjectInChainMayInterceptIndexedAccesses const):
1250         (JSC::JSObject::prototypeChainMayInterceptStoreTo):
1251         * runtime/JSObject.h:
1252         (JSC::JSObject::finishCreation):
1253         (JSC::JSObject::getPrototypeDirect const):
1254         (JSC::JSObject::getPrototype):
1255         * runtime/JSObjectInlines.h:
1256         (JSC::JSObject::canPerformFastPutInline):
1257         (JSC::JSObject::getPropertySlot):
1258         (JSC::JSObject::getNonIndexPropertySlot):
1259         * runtime/JSProxy.cpp:
1260         (JSC::JSProxy::setTarget):
1261         * runtime/JSSet.cpp:
1262         (JSC::JSSet::isIteratorProtocolFastAndNonObservable):
1263         * runtime/ProgramExecutable.cpp:
1264         (JSC::ProgramExecutable::initializeGlobalProperties):
1265         * runtime/StructureInlines.h:
1266         (JSC::Structure::isValid const):
1267
1268 2017-10-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1269
1270         [ARM64] static_cast<int32_t>() in BinaryOpNode::emitBytecode() prevents op_unsigned emission
1271         https://bugs.webkit.org/show_bug.cgi?id=178379
1272
1273         Reviewed by Saam Barati.
1274
1275         We reuse jsNumber's checking mechanism here to precisely check the generated number is within uint32_t
1276         in bytecode compiler. This is reasonable since the NumberNode will generate the exact this JSValue.
1277
1278         * bytecompiler/NodesCodegen.cpp:
1279         (JSC::BinaryOpNode::emitBytecode):
1280
1281 2017-10-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1282
1283         [JSC] ScriptFetcher should be notified directly from module pipeline
1284         https://bugs.webkit.org/show_bug.cgi?id=178340
1285
1286         Reviewed by Sam Weinig.
1287
1288         Previously, we use JSStdFunction to let WebCore inform the module pipeline results.
1289         We setup JSStdFunction to the resulted promise of the module pipeline. It is super
1290         ad-hoc since JSStdFunction's lambda need extra-careful to make it non-cyclic-referenced.
1291         JSStdFunction's lambda can capture variables, but they are not able to be marked by GC.
1292
1293         But now, we have ScriptFetcher. It is introduced after we implemented the module pipeline
1294         notification mechanism by using JSStdFunction. But it is appropriate one to receive notification
1295         from the module pipeline by observer style.
1296
1297         This patch removes the above ad-hoc JSStdFunction use. And now ScriptFetcher receives
1298         completion/failure notifications from the module pipeline.
1299
1300         * builtins/ModuleLoaderPrototype.js:
1301         (loadModule):
1302         (loadAndEvaluateModule):
1303         * runtime/Completion.cpp:
1304         (JSC::loadModule):
1305         * runtime/Completion.h:
1306         * runtime/JSModuleLoader.cpp:
1307         (JSC::jsValueToModuleKey):
1308         (JSC::JSModuleLoader::notifyCompleted):
1309         (JSC::JSModuleLoader::notifyFailed):
1310         * runtime/JSModuleLoader.h:
1311         * runtime/ModuleLoaderPrototype.cpp:
1312         (JSC::moduleLoaderPrototypeNotifyCompleted):
1313         (JSC::moduleLoaderPrototypeNotifyFailed):
1314         * runtime/ScriptFetcher.h:
1315         (JSC::ScriptFetcher::notifyLoadCompleted):
1316         (JSC::ScriptFetcher::notifyLoadFailed):
1317
1318 2017-10-19  JF Bastien  <jfbastien@apple.com>
1319
1320         WebAssembly: no VM / JS version of everything but Instance
1321         https://bugs.webkit.org/show_bug.cgi?id=177473
1322
1323         Reviewed by Filip Pizlo, Saam Barati.
1324
1325         This change entails cleaning up and splitting a bunch of code which we had
1326         intertwined between C++ classes which represent JS objects, and pure C++
1327         implementation objects. This specific change goes most of the way towards
1328         allowing JSC's WebAssembly to work without VM / JS, up to but excluding
1329         JSWebAssemblyInstance (there's Wasm::Instance, but it's not *the* thing
1330         yet). Because of this we still have a few FIXME identifying places that need to
1331         change. A follow-up change will go the rest of the way.
1332
1333         I went about this change in the simplest way possible: grep the
1334         JavaScriptCore/wasm directory for "JS[^C_]" as well as "VM" and exclude the /js/
1335         sub-directory (which contains the JS implementation of WebAssembly).
1336
1337         None of this change removes the need for a JIT entitlement to be able to use
1338         WebAssembly. We don't have an interpreter, the process therefore still needs to
1339         be allowed to JIT to use these pure-C++ APIs.
1340
1341         Interesting things to note:
1342
1343           - Remove VM from Plan and associated places. It can just live as a capture in
1344             the callback lambda if it's needed.
1345           - Wasm::Memory shouldn't require a VM. It was only used to ask the GC to
1346             collect. We now instead pass two lambdas at construction time for this
1347             purpose: one to notify of memory pressure, and the other to ask for
1348             syncrhonous memory reclamation. This allows whoever creates the memory to
1349             dictate how to react to both these cases, and for a JS embedding that's to
1350             call the GC (async or sync, respectively).
1351           - Move grow logic from JSWebAssemblyMemory to Wasm::Memory::grow. Use Expected
1352             there, with an enum class for failure types.
1353           - Exceeding max on memory growth now returns a range error as per spec. This
1354             is a (very minor) breaking change: it used to throw OOM error. Update the
1355             corresponding test.
1356           - When generating the grow_memory opcode, no need to get the VM. Instead,
1357             reach directly for Wasm::Memory and grow it.
1358           - JSWebAssemblyMemory::grow can now always throw on failure, because it's only
1359             ever called from JS (not from grow_memory as before).
1360           - Wasm::Memory now takes a callback for successful growth. This allows JS
1361             wrappers to register themselves when growth succeeds without Wasm::Memory
1362             knowning anything about JS. It'll also allow creating a list of callbacks
1363             for when we add thread support (we'll want to notify many wrappers, all
1364             under a lock).
1365           - Wasm::Memory is now back to being the source of truth about address / size,
1366             used directly by generated code instead of JSWebAssemblyMemory.
1367           - Move wasmToJS from the general WasmBinding header to its own header under
1368             wasm/js. It's only used by wasm/js/JSWebAssemblyCodeBlock.cpp, and uses VM,
1369             and therefore isn't general WebAssembly.
1370           - Make Wasm::Context an actual type (just a struct holding a
1371             JSWebAssemlyInstance for now) instead of an alias for that. Notably this
1372             doesn't add anything to the Context and doesn't change what actually gets
1373             passed around in JIT code (fast TLS or registers) because these changes
1374             potentially impact performance. The entire purpose of this change is to
1375             allow passing Wasm::Context around without having to know about VM. Since VM
1376             contains a Wasm::Context the JS embedding is effectively the same, but with
1377             this setup a non-JS embedding is much better off.
1378           - Move JSWebAssembly into the JS folder.
1379           - OMGPlan: use Wasm::CodeBlock directly instead of JSWebAssemblyCodeBlock.
1380           - wasm->JS stubs are now on the instance's tail as raw pointers, instead of
1381             being on JSWebAssemblyCodeBlock, and are now called wasm->Embedder
1382             stubs. The owned reference is still on JSWebAssemblyCodeBlock, and is still
1383             called wasm->JS stub. This move means that the embedder must, after creating
1384             a Wasm::CodeBlock, somehow create the stubs to call back into the
1385             embedder. This removes an indirection in the generated code because
1386             the B3 IR generator now reaches into the instance instead of
1387             JSWebAssemblyCodeBlock.
1388           - Move more CodeBlock things. Compilation completion is now marked by its own
1389             atomic<bool> flag instead of a nullptr plan: that required using a lock, and
1390             was causing a deadlock in stack-trace.js because before my changes
1391             JSWebAssemblyCodeBlock did its own completion checking separately from
1392             Wasm::CodeBlock, without getting the lock. Now that everything points to
1393             Wasm::CodeBlock and there's no cached completion marker, the lock was being
1394             acquired in a sanity-check assertion.
1395           - Embedder -> Wasm wrappers are now generated through a function that's passed
1396             in at compilation time, instead of being hard-coded as a JS -> Wasm wrapper.
1397           - WasmMemory doens't need to know about fault handling thunks. Only the IR
1398             generator should know, and should make sure that the exception throwing
1399             thunk is generated if any memory is present (note: with signal handling not
1400             all of them generate an exception check).
1401           - Make exception throwing pluggable: instead of having a hard-coded
1402             JS-specific lambda we now have a regular C++ function being called from JIT
1403             code when a WebAssembly exception is thrown. This allows any embedder to get
1404             called as they wish. For now a process can only have a single of these
1405             functions (i.e. only one embedder per process) because the trap handler is a
1406             singleton. That can be fixed in in #177475.
1407           - Create WasmEmbedder.h where all embedder plugging will live.
1408           - Split up JSWebAssemblyTable into Wasm::Table which is
1409             refcounted. JSWebAssemblyTable now only contains the JS functions in the
1410             table, and Wasm::Table is what's used by the JIT code to lookup where to
1411             call and do the instance check (for context switch). Note that this creates
1412             an extra allocation for all the instances in Wasm::Table, and in exchange
1413             removes an indirection in JIT code because the instance used to be obtained
1414             off of the JS function. Also note that it's the embedder than keeps the
1415             instances alive, not Wasm::Table (which holds a dumb pointer to the
1416             instance), because doing otherwise would cause reference cycles.
1417            - Add WasmInstance. It doesn't do much for now, owns globals.
1418            - JSWebAssembly instance now doesn't just contain the imported functions as
1419              JSObjects, it also has the corresponding import's instance and wasm
1420              entrypoint. This triples the space allocated per instance's imported
1421              function, but there shouldn't be that many imports. This has two upsides: it
1422              creates smaller and faster code, and makes is easier to disassociate
1423              embedder-specific things from embedder-neutral things. The small / faster
1424              win is in two places: B3 IR generator only needs offsetOfImportFunction for
1425              the call opcode (when the called index is an import) to know whether the
1426              import is wasm->wasm or wasm->embedder (this isn't known at compile-time
1427              because it's dependent on the import object), this is now done by seeing if
1428              that import function has an associated target instance (only wasm->wasm
1429              does); the other place is wasmBinding which uses offsetOfImportFunction to
1430              figure out the wasm->wasm target instance, and then gets
1431              WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation to do a tail
1432              call. The disassociation comes because the target instance can be
1433              Wasm::Instance once we change what the Context is, and
1434              WasmEntrypointLoadLocation is already embedder-independent. As a next step I
1435              can move this tail allocation from JSWebAssemblyInstance to Wasm::Instance,
1436              and leave importFunction in as an opaque pointer which is embedder-specific,
1437              and in JS will remain WriteBarrier<JSObject>.
1438            - Rename VMEntryFrame to EntryFrame, and in many places pass a pointer to it
1439              around instead of VM. This is a first step in allowing entry frames which
1440              aren't stored on VM, but which are instead stored in an embedder-specific
1441              location. That change won't really affect JS except through code churn, but
1442              will allow WebAssembly to use some machinery in a generic manner without
1443              having a VM.
1444
1445         * JavaScriptCore.xcodeproj/project.pbxproj:
1446         * Sources.txt:
1447         * bytecode/PolymorphicAccess.cpp:
1448         (JSC::AccessGenerationState::emitExplicitExceptionHandler):
1449         * debugger/Debugger.cpp:
1450         (JSC::Debugger::stepOutOfFunction):
1451         (JSC::Debugger::returnEvent):
1452         (JSC::Debugger::unwindEvent):
1453         (JSC::Debugger::didExecuteProgram):
1454         * dfg/DFGJITCompiler.cpp:
1455         (JSC::DFG::JITCompiler::compileExceptionHandlers):
1456         * dfg/DFGOSREntry.cpp:
1457         (JSC::DFG::prepareOSREntry):
1458         * dfg/DFGOSRExit.cpp:
1459         (JSC::DFG::OSRExit::compileOSRExit):
1460         (JSC::DFG::OSRExit::compileExit):
1461         * dfg/DFGThunks.cpp:
1462         (JSC::DFG::osrEntryThunkGenerator):
1463         * ftl/FTLCompile.cpp:
1464         (JSC::FTL::compile):
1465         * ftl/FTLLink.cpp:
1466         (JSC::FTL::link):
1467         * ftl/FTLLowerDFGToB3.cpp:
1468         (JSC::FTL::DFG::LowerDFGToB3::lower):
1469         * ftl/FTLOSRExitCompiler.cpp:
1470         (JSC::FTL::compileStub):
1471         * interpreter/CallFrame.cpp:
1472         (JSC::CallFrame::wasmAwareLexicalGlobalObject):
1473         (JSC::CallFrame::callerFrame):
1474         (JSC::CallFrame::unsafeCallerFrame):
1475         * interpreter/CallFrame.h:
1476         (JSC::ExecState::callerFrame const):
1477         (JSC::ExecState::callerFrameOrEntryFrame const):
1478         (JSC::ExecState::unsafeCallerFrameOrEntryFrame const):
1479         * interpreter/FrameTracers.h:
1480         (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
1481         (JSC::NativeCallFrameTracerWithRestore::NativeCallFrameTracerWithRestore):
1482         (JSC::NativeCallFrameTracerWithRestore::~NativeCallFrameTracerWithRestore):
1483         * interpreter/Interpreter.cpp:
1484         (JSC::UnwindFunctor::operator() const):
1485         (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
1486         (JSC::Interpreter::unwind):
1487         * interpreter/StackVisitor.cpp:
1488         (JSC::StackVisitor::StackVisitor):
1489         (JSC::StackVisitor::gotoNextFrame):
1490         (JSC::StackVisitor::readNonInlinedFrame):
1491         (JSC::StackVisitor::Frame::dump const):
1492         * interpreter/StackVisitor.h:
1493         (JSC::StackVisitor::Frame::callerIsEntryFrame const):
1494         * interpreter/VMEntryRecord.h:
1495         (JSC::VMEntryRecord::prevTopEntryFrame):
1496         (JSC::VMEntryRecord::unsafePrevTopEntryFrame):
1497         (JSC::EntryFrame::vmEntryRecordOffset):
1498         * jit/AssemblyHelpers.cpp:
1499         (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
1500         (JSC::AssemblyHelpers::loadWasmContextInstance):
1501         (JSC::AssemblyHelpers::storeWasmContextInstance):
1502         (JSC::AssemblyHelpers::loadWasmContextInstanceNeedsMacroScratchRegister):
1503         (JSC::AssemblyHelpers::storeWasmContextInstanceNeedsMacroScratchRegister):
1504         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
1505         * jit/AssemblyHelpers.h:
1506         (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
1507         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer):
1508         (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer):
1509         * jit/JIT.cpp:
1510         (JSC::JIT::emitEnterOptimizationCheck):
1511         (JSC::JIT::privateCompileExceptionHandlers):
1512         * jit/JITExceptions.cpp:
1513         (JSC::genericUnwind):
1514         * jit/JITOpcodes.cpp:
1515         (JSC::JIT::emit_op_throw):
1516         (JSC::JIT::emit_op_catch):
1517         (JSC::JIT::emitSlow_op_loop_hint):
1518         * jit/JITOpcodes32_64.cpp:
1519         (JSC::JIT::emit_op_throw):
1520         (JSC::JIT::emit_op_catch):
1521         * jit/JITOperations.cpp:
1522         * jit/ThunkGenerators.cpp:
1523         (JSC::throwExceptionFromCallSlowPathGenerator):
1524         (JSC::nativeForGenerator):
1525         * jsc.cpp:
1526         (functionDumpCallFrame):
1527         * llint/LLIntSlowPaths.cpp:
1528         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1529         * llint/LLIntThunks.cpp:
1530         (JSC::vmEntryRecord):
1531         * llint/LowLevelInterpreter.asm:
1532         * llint/LowLevelInterpreter32_64.asm:
1533         * llint/LowLevelInterpreter64.asm:
1534         * runtime/Options.cpp:
1535         (JSC::recomputeDependentOptions):
1536         * runtime/Options.h:
1537         * runtime/SamplingProfiler.cpp:
1538         (JSC::FrameWalker::FrameWalker):
1539         (JSC::FrameWalker::advanceToParentFrame):
1540         (JSC::SamplingProfiler::processUnverifiedStackTraces):
1541         * runtime/ThrowScope.cpp:
1542         (JSC::ThrowScope::~ThrowScope):
1543         * runtime/VM.cpp:
1544         (JSC::VM::VM):
1545         (JSC::VM::~VM):
1546         * runtime/VM.h:
1547         (JSC::VM::topEntryFrameOffset):
1548         * runtime/VMTraps.cpp:
1549         (JSC::isSaneFrame):
1550         (JSC::VMTraps::tryInstallTrapBreakpoints):
1551         (JSC::VMTraps::invalidateCodeBlocksOnStack):
1552         * wasm/WasmB3IRGenerator.cpp:
1553         (JSC::Wasm::B3IRGenerator::restoreWasmContextInstance):
1554         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1555         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
1556         (JSC::Wasm::B3IRGenerator::addGrowMemory):
1557         (JSC::Wasm::B3IRGenerator::addCurrentMemory):
1558         (JSC::Wasm::B3IRGenerator::addCall):
1559         (JSC::Wasm::B3IRGenerator::addCallIndirect):
1560         (JSC::Wasm::parseAndCompile):
1561         * wasm/WasmB3IRGenerator.h:
1562         * wasm/WasmBBQPlan.cpp:
1563         (JSC::Wasm::BBQPlan::BBQPlan):
1564         (JSC::Wasm::BBQPlan::compileFunctions):
1565         (JSC::Wasm::BBQPlan::complete):
1566         * wasm/WasmBBQPlan.h:
1567         * wasm/WasmBBQPlanInlines.h:
1568         (JSC::Wasm::BBQPlan::initializeCallees):
1569         * wasm/WasmBinding.cpp:
1570         (JSC::Wasm::wasmToWasm):
1571         * wasm/WasmBinding.h:
1572         * wasm/WasmCodeBlock.cpp:
1573         (JSC::Wasm::CodeBlock::create):
1574         (JSC::Wasm::CodeBlock::CodeBlock):
1575         (JSC::Wasm::CodeBlock::compileAsync):
1576         (JSC::Wasm::CodeBlock::setCompilationFinished):
1577         * wasm/WasmCodeBlock.h:
1578         (JSC::Wasm::CodeBlock::offsetOfImportStubs):
1579         (JSC::Wasm::CodeBlock::allocationSize):
1580         (JSC::Wasm::CodeBlock::importWasmToEmbedderStub):
1581         (JSC::Wasm::CodeBlock::offsetOfImportWasmToEmbedderStub):
1582         (JSC::Wasm::CodeBlock::wasmToJSCallStubForImport):
1583         (JSC::Wasm::CodeBlock::compilationFinished):
1584         (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
1585         (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
1586         * wasm/WasmContext.cpp:
1587         (JSC::Wasm::Context::useFastTLS):
1588         (JSC::Wasm::Context::load const):
1589         (JSC::Wasm::Context::store):
1590         * wasm/WasmContext.h:
1591         * wasm/WasmEmbedder.h: Copied from Source/JavaScriptCore/wasm/WasmContext.h.
1592         * wasm/WasmFaultSignalHandler.cpp:
1593         * wasm/WasmFaultSignalHandler.h:
1594         * wasm/WasmFormat.h:
1595         * wasm/WasmInstance.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
1596         (JSC::Wasm::Instance::Instance):
1597         (JSC::Wasm::Instance::~Instance):
1598         (JSC::Wasm::Instance::extraMemoryAllocated const):
1599         * wasm/WasmInstance.h: Added.
1600         (JSC::Wasm::Instance::create):
1601         (JSC::Wasm::Instance::finalizeCreation):
1602         (JSC::Wasm::Instance::module):
1603         (JSC::Wasm::Instance::codeBlock):
1604         (JSC::Wasm::Instance::memory):
1605         (JSC::Wasm::Instance::table):
1606         (JSC::Wasm::Instance::loadI32Global const):
1607         (JSC::Wasm::Instance::loadI64Global const):
1608         (JSC::Wasm::Instance::loadF32Global const):
1609         (JSC::Wasm::Instance::loadF64Global const):
1610         (JSC::Wasm::Instance::setGlobal):
1611         (JSC::Wasm::Instance::offsetOfCachedStackLimit):
1612         (JSC::Wasm::Instance::cachedStackLimit const):
1613         (JSC::Wasm::Instance::setCachedStackLimit):
1614         * wasm/WasmMemory.cpp:
1615         (JSC::Wasm::Memory::Memory):
1616         (JSC::Wasm::Memory::create):
1617         (JSC::Wasm::Memory::~Memory):
1618         (JSC::Wasm::Memory::grow):
1619         * wasm/WasmMemory.h:
1620         (JSC::Wasm::Memory::offsetOfMemory):
1621         (JSC::Wasm::Memory::offsetOfSize):
1622         * wasm/WasmMemoryInformation.cpp:
1623         (JSC::Wasm::PinnedRegisterInfo::get):
1624         (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
1625         * wasm/WasmMemoryInformation.h:
1626         (JSC::Wasm::PinnedRegisterInfo::toSave const):
1627         * wasm/WasmMemoryMode.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
1628         (JSC::Wasm::makeString):
1629         * wasm/WasmMemoryMode.h: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
1630         * wasm/WasmModule.cpp:
1631         (JSC::Wasm::makeValidationCallback):
1632         (JSC::Wasm::Module::validateSync):
1633         (JSC::Wasm::Module::validateAsync):
1634         (JSC::Wasm::Module::getOrCreateCodeBlock):
1635         (JSC::Wasm::Module::compileSync):
1636         (JSC::Wasm::Module::compileAsync):
1637         * wasm/WasmModule.h:
1638         * wasm/WasmModuleParser.cpp:
1639         (JSC::Wasm::ModuleParser::parseTableHelper):
1640         * wasm/WasmOMGPlan.cpp:
1641         (JSC::Wasm::OMGPlan::OMGPlan):
1642         (JSC::Wasm::OMGPlan::runForIndex):
1643         * wasm/WasmOMGPlan.h:
1644         * wasm/WasmPageCount.h:
1645         (JSC::Wasm::PageCount::isValid const):
1646         * wasm/WasmPlan.cpp:
1647         (JSC::Wasm::Plan::Plan):
1648         (JSC::Wasm::Plan::runCompletionTasks):
1649         (JSC::Wasm::Plan::addCompletionTask):
1650         (JSC::Wasm::Plan::tryRemoveContextAndCancelIfLast):
1651         * wasm/WasmPlan.h:
1652         (JSC::Wasm::Plan::dontFinalize):
1653         * wasm/WasmSignature.cpp:
1654         * wasm/WasmSignature.h:
1655         * wasm/WasmTable.cpp: Added.
1656         (JSC::Wasm::Table::create):
1657         (JSC::Wasm::Table::~Table):
1658         (JSC::Wasm::Table::Table):
1659         (JSC::Wasm::Table::grow):
1660         (JSC::Wasm::Table::clearFunction):
1661         (JSC::Wasm::Table::setFunction):
1662         * wasm/WasmTable.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.h.
1663         (JSC::Wasm::Table::maximum const):
1664         (JSC::Wasm::Table::size const):
1665         (JSC::Wasm::Table::offsetOfSize):
1666         (JSC::Wasm::Table::offsetOfFunctions):
1667         (JSC::Wasm::Table::offsetOfInstances):
1668         (JSC::Wasm::Table::isValidSize):
1669         * wasm/WasmThunks.cpp:
1670         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
1671         (JSC::Wasm::triggerOMGTierUpThunkGenerator):
1672         (JSC::Wasm::Thunks::setThrowWasmException):
1673         (JSC::Wasm::Thunks::throwWasmException):
1674         * wasm/WasmThunks.h:
1675         * wasm/WasmWorklist.cpp:
1676         (JSC::Wasm::Worklist::stopAllPlansForContext):
1677         * wasm/WasmWorklist.h:
1678         * wasm/js/JSToWasm.cpp: Added.
1679         (JSC::Wasm::createJSToWasmWrapper):
1680         * wasm/js/JSToWasm.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
1681         * wasm/js/JSWebAssembly.cpp: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.cpp.
1682         * wasm/js/JSWebAssembly.h: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.h.
1683         * wasm/js/JSWebAssemblyCodeBlock.cpp:
1684         (JSC::JSWebAssemblyCodeBlock::create):
1685         (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
1686         * wasm/js/JSWebAssemblyCodeBlock.h:
1687         * wasm/js/JSWebAssemblyInstance.cpp:
1688         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
1689         (JSC::JSWebAssemblyInstance::finishCreation):
1690         (JSC::JSWebAssemblyInstance::visitChildren):
1691         (JSC::JSWebAssemblyInstance::finalizeCreation):
1692         (JSC::JSWebAssemblyInstance::create):
1693         * wasm/js/JSWebAssemblyInstance.h:
1694         (JSC::JSWebAssemblyInstance::instance):
1695         (JSC::JSWebAssemblyInstance::context const):
1696         (JSC::JSWebAssemblyInstance::table):
1697         (JSC::JSWebAssemblyInstance::webAssemblyToJSCallee):
1698         (JSC::JSWebAssemblyInstance::setMemory):
1699         (JSC::JSWebAssemblyInstance::offsetOfTail):
1700         (JSC::JSWebAssemblyInstance::importFunctionInfo):
1701         (JSC::JSWebAssemblyInstance::offsetOfTargetInstance):
1702         (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint):
1703         (JSC::JSWebAssemblyInstance::offsetOfImportFunction):
1704         (JSC::JSWebAssemblyInstance::importFunction):
1705         (JSC::JSWebAssemblyInstance::internalMemory):
1706         (JSC::JSWebAssemblyInstance::wasmCodeBlock const):
1707         (JSC::JSWebAssemblyInstance::offsetOfWasmTable):
1708         (JSC::JSWebAssemblyInstance::offsetOfCallee):
1709         (JSC::JSWebAssemblyInstance::offsetOfGlobals):
1710         (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock):
1711         (JSC::JSWebAssemblyInstance::offsetOfWasmMemory):
1712         (JSC::JSWebAssemblyInstance::cachedStackLimit const):
1713         (JSC::JSWebAssemblyInstance::setCachedStackLimit):
1714         (JSC::JSWebAssemblyInstance::wasmMemory):
1715         (JSC::JSWebAssemblyInstance::wasmModule):
1716         (JSC::JSWebAssemblyInstance::allocationSize):
1717         (JSC::JSWebAssemblyInstance::module const):
1718         * wasm/js/JSWebAssemblyMemory.cpp:
1719         (JSC::JSWebAssemblyMemory::create):
1720         (JSC::JSWebAssemblyMemory::adopt):
1721         (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
1722         (JSC::JSWebAssemblyMemory::grow):
1723         (JSC::JSWebAssemblyMemory::growSuccessCallback):
1724         * wasm/js/JSWebAssemblyMemory.h:
1725         * wasm/js/JSWebAssemblyModule.cpp:
1726         (JSC::JSWebAssemblyModule::moduleInformation const):
1727         (JSC::JSWebAssemblyModule::exportSymbolTable const):
1728         (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace const):
1729         (JSC::JSWebAssemblyModule::callee const):
1730         (JSC::JSWebAssemblyModule::codeBlock):
1731         (JSC::JSWebAssemblyModule::module):
1732         * wasm/js/JSWebAssemblyModule.h:
1733         * wasm/js/JSWebAssemblyTable.cpp:
1734         (JSC::JSWebAssemblyTable::create):
1735         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
1736         (JSC::JSWebAssemblyTable::visitChildren):
1737         (JSC::JSWebAssemblyTable::grow):
1738         (JSC::JSWebAssemblyTable::getFunction):
1739         (JSC::JSWebAssemblyTable::clearFunction):
1740         (JSC::JSWebAssemblyTable::setFunction):
1741         * wasm/js/JSWebAssemblyTable.h:
1742         (JSC::JSWebAssemblyTable::isValidSize):
1743         (JSC::JSWebAssemblyTable::maximum const):
1744         (JSC::JSWebAssemblyTable::size const):
1745         (JSC::JSWebAssemblyTable::table):
1746         * wasm/js/WasmToJS.cpp: Copied from Source/JavaScriptCore/wasm/WasmBinding.cpp.
1747         (JSC::Wasm::materializeImportJSCell):
1748         (JSC::Wasm::wasmToJS):
1749         (JSC::Wasm::wasmToJSException):
1750         * wasm/js/WasmToJS.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
1751         * wasm/js/WebAssemblyFunction.cpp:
1752         (JSC::callWebAssemblyFunction):
1753         * wasm/js/WebAssemblyInstanceConstructor.cpp:
1754         (JSC::constructJSWebAssemblyInstance):
1755         * wasm/js/WebAssemblyMemoryConstructor.cpp:
1756         (JSC::constructJSWebAssemblyMemory):
1757         * wasm/js/WebAssemblyMemoryPrototype.cpp:
1758         (JSC::webAssemblyMemoryProtoFuncGrow):
1759         * wasm/js/WebAssemblyModuleConstructor.cpp:
1760         (JSC::constructJSWebAssemblyModule):
1761         (JSC::WebAssemblyModuleConstructor::createModule):
1762         * wasm/js/WebAssemblyModuleConstructor.h:
1763         * wasm/js/WebAssemblyModuleRecord.cpp:
1764         (JSC::WebAssemblyModuleRecord::link):
1765         (JSC::WebAssemblyModuleRecord::evaluate):
1766         * wasm/js/WebAssemblyPrototype.cpp:
1767         (JSC::webAssemblyCompileFunc):
1768         (JSC::instantiate):
1769         (JSC::compileAndInstantiate):
1770         (JSC::webAssemblyValidateFunc):
1771         * wasm/js/WebAssemblyTableConstructor.cpp:
1772         (JSC::constructJSWebAssemblyTable):
1773         * wasm/js/WebAssemblyWrapperFunction.cpp:
1774         (JSC::WebAssemblyWrapperFunction::create):
1775
1776 2017-10-19  Mark Lam  <mark.lam@apple.com>
1777
1778         Stringifier::appendStringifiedValue() is missing an exception check.
1779         https://bugs.webkit.org/show_bug.cgi?id=178386
1780         <rdar://problem/35027610>
1781
1782         Reviewed by Saam Barati.
1783
1784         * runtime/JSONObject.cpp:
1785         (JSC::Stringifier::appendStringifiedValue):
1786
1787 2017-10-19  Saam Barati  <sbarati@apple.com>
1788
1789         REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning: comparison is always false due to limited range of data type [-Wtype-limits]
1790         https://bugs.webkit.org/show_bug.cgi?id=178543
1791
1792         Reviewed by Filip Pizlo.
1793
1794         * dfg/DFGByteCodeParser.cpp:
1795         (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
1796
1797 2017-10-19  Saam Barati  <sbarati@apple.com>
1798
1799         re-inline ObjectAllocationProfile::initializeProfile
1800         https://bugs.webkit.org/show_bug.cgi?id=178532
1801
1802         Rubber stamped by Michael Saboff.
1803
1804         I un-inlined this function when implementing poly proto.
1805         This patch re-inlines it. In my testing, it looks like it
1806         might be a 0.5% speedometer progression to inline it.
1807
1808         * JavaScriptCore.xcodeproj/project.pbxproj:
1809         * Sources.txt:
1810         * bytecode/CodeBlock.cpp:
1811         * bytecode/ObjectAllocationProfile.cpp: Removed.
1812         * bytecode/ObjectAllocationProfileInlines.h: Copied from Source/JavaScriptCore/bytecode/ObjectAllocationProfile.cpp.
1813         (JSC::ObjectAllocationProfile::initializeProfile):
1814         (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
1815         * runtime/FunctionRareData.cpp:
1816
1817 2017-10-19  Michael Saboff  <msaboff@apple.com>
1818
1819         Test262: RegExp/property-escapes/generated/Emoji_Component.js fails with current RegExp Unicode Properties implementation
1820         https://bugs.webkit.org/show_bug.cgi?id=178521
1821
1822         Reviewed by JF Bastien.
1823
1824         * ucd/emoji-data.txt: Replaced with the Unicode Emoji 5.0 version of the file as that is the most recent
1825         standard version.  The prior version was the draft 6.0 version.
1826
1827 2017-10-19  Saam Barati  <sbarati@apple.com>
1828
1829         We should hard code the poly proto offset
1830         https://bugs.webkit.org/show_bug.cgi?id=178531
1831
1832         Reviewed by Filip Pizlo.
1833
1834         This patch embraces that the poly proto offset is always zero. It's already
1835         the case that we would always get the inline offset zero for poly proto just
1836         by construction. This just hardcodes this assumption throughout the codebase.
1837         This appears to be a 1% speedometer progression in my testing.
1838         
1839         The downside of this patch is that it may require changing how we do
1840         things when we implement poly proto when inheriting from builtin
1841         types. I think we can face this problem when we decide to implement
1842         that.
1843
1844         * bytecode/AccessCase.cpp:
1845         (JSC::AccessCase::generateWithGuard):
1846         * dfg/DFGOperations.cpp:
1847         * dfg/DFGSpeculativeJIT.cpp:
1848         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
1849         (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
1850         * ftl/FTLLowerDFGToB3.cpp:
1851         (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
1852         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
1853         * jit/JITOpcodes.cpp:
1854         (JSC::JIT::emit_op_instanceof):
1855         * jit/JITOpcodes32_64.cpp:
1856         (JSC::JIT::emit_op_instanceof):
1857         * runtime/CommonSlowPaths.cpp:
1858         (JSC::SLOW_PATH_DECL):
1859         * runtime/JSObject.cpp:
1860         (JSC::JSObject::setPrototypeDirect):
1861         * runtime/JSObject.h:
1862         (JSC::JSObject::locationForOffset const):
1863         (JSC::JSObject::locationForOffset):
1864         (JSC::JSObject::getDirect const):
1865         * runtime/PropertyOffset.h:
1866         * runtime/Structure.cpp:
1867         (JSC::Structure::create):
1868         (JSC::Structure::dump const):
1869         * runtime/Structure.h:
1870         * runtime/StructureInlines.h:
1871         (JSC::Structure::storedPrototype const):
1872         (JSC::Structure::storedPrototypeObject const):
1873
1874 2017-10-19  Saam Barati  <sbarati@apple.com>
1875
1876         Turn various poly proto RELEASE_ASSERTs into ASSERTs because they're on the hot path in speedometer
1877         https://bugs.webkit.org/show_bug.cgi?id=178529
1878
1879         Reviewed by Mark Lam.
1880
1881         * runtime/Structure.h:
1882         * runtime/StructureInlines.h:
1883         (JSC::Structure::storedPrototypeObject const):
1884         (JSC::Structure::storedPrototypeStructure const):
1885         (JSC::Structure::storedPrototype const):
1886         (JSC::Structure::prototypeForLookup const):
1887         (JSC::Structure::prototypeChain const):
1888
1889 2017-10-19  Saam Barati  <sbarati@apple.com>
1890
1891         Turn poly proto back on by default and remove the option
1892         https://bugs.webkit.org/show_bug.cgi?id=178525
1893
1894         Reviewed by Mark Lam.
1895
1896         I added this option because I thought it'd speed speedometer up because the
1897         original poly proto patch slowed speedometer down. It turns out that
1898         allocating poly proto objects is not what slows speedometer down. It's
1899         other code I added in the runtime that needs to be poly proto aware. I'll
1900         be addressing these in follow up patches.
1901
1902         * runtime/Options.h:
1903         * runtime/StructureInlines.h:
1904         (JSC::Structure::shouldConvertToPolyProto):
1905
1906 2017-10-19  Robin Morisset  <rmorisset@apple.com>
1907
1908         Turn recursive tail calls into loops
1909         https://bugs.webkit.org/show_bug.cgi?id=176601
1910
1911         Reviewed by Saam Barati.
1912
1913         We want to turn recursive tail calls into loops early in the pipeline, so that the loops can then be optimized.
1914         One difficulty is that we need to split the entry block of the function we are jumping to in order to have somewhere to jump to.
1915         Worse: it is not necessarily the first block of the codeBlock, because of inlining! So we must do the splitting in the DFGByteCodeParser, at the same time as inlining.
1916         We do this part through modifying the computation of the jump targets.
1917         Importantly, we only do this splitting for functions that have tail calls.
1918         It is the only case where the optimisation is sound, and doing the splitting unconditionnaly destroys performance on Octane/raytrace.
1919
1920         We must then do the actual transformation also in DFGByteCodeParser, to avoid code motion moving code out of the body of what will become a loop.
1921         The transformation is entirely contained in handleRecursiveTailCall, which is hooked to the inlining machinery.
1922
1923         * bytecode/CodeBlock.h:
1924         (JSC::CodeBlock::hasTailCalls const):
1925         * bytecode/PreciseJumpTargets.cpp:
1926         (JSC::getJumpTargetsForBytecodeOffset):
1927         (JSC::computePreciseJumpTargetsInternal):
1928         * bytecode/UnlinkedCodeBlock.cpp:
1929         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
1930         * bytecode/UnlinkedCodeBlock.h:
1931         (JSC::UnlinkedCodeBlock::hasTailCalls const):
1932         (JSC::UnlinkedCodeBlock::setHasTailCalls):
1933         * bytecompiler/BytecodeGenerator.cpp:
1934         (JSC::BytecodeGenerator::emitEnter):
1935         (JSC::BytecodeGenerator::emitCallInTailPosition):
1936         * dfg/DFGByteCodeParser.cpp:
1937         (JSC::DFG::ByteCodeParser::allocateTargetableBlock):
1938         (JSC::DFG::ByteCodeParser::makeBlockTargetable):
1939         (JSC::DFG::ByteCodeParser::handleCall):
1940         (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
1941         (JSC::DFG::ByteCodeParser::parseBlock):
1942         (JSC::DFG::ByteCodeParser::parse):
1943
1944 2017-10-18  Mark Lam  <mark.lam@apple.com>
1945
1946         RegExpObject::defineOwnProperty() does not need to compare values if no descriptor value is specified.
1947         https://bugs.webkit.org/show_bug.cgi?id=177600
1948         <rdar://problem/34710985>
1949
1950         Reviewed by Saam Barati.
1951
1952         According to http://www.ecma-international.org/ecma-262/8.0/#sec-validateandapplypropertydescriptor,
1953         section 9.1.6.3-7.a.ii, we should only check if the value is the same if the
1954         descriptor value is present.
1955
1956         * runtime/RegExpObject.cpp:
1957         (JSC::RegExpObject::defineOwnProperty):
1958
1959 2017-10-18  Keith Miller  <keith_miller@apple.com>
1960
1961         Setup WebCore build to start using unified sources.
1962         https://bugs.webkit.org/show_bug.cgi?id=178362
1963
1964         Reviewed by Tim Horton.
1965
1966         Change comments in source list files. Also, pass explicit names for build files.
1967
1968         * CMakeLists.txt:
1969         * PlatformGTK.cmake:
1970         * PlatformMac.cmake:
1971         * Sources.txt:
1972         * SourcesGTK.txt:
1973         * SourcesMac.txt:
1974
1975 2017-10-18  Commit Queue  <commit-queue@webkit.org>
1976
1977         Unreviewed, rolling out r223321.
1978         https://bugs.webkit.org/show_bug.cgi?id=178476
1979
1980         This protocol change broke some internal builds (Requested by
1981         brrian__ on #webkit).
1982
1983         Reverted changeset:
1984
1985         "Web Inspector: provide a way to enable/disable event
1986         listeners"
1987         https://bugs.webkit.org/show_bug.cgi?id=177451
1988         https://trac.webkit.org/changeset/223321
1989
1990 2017-10-18  Mark Lam  <mark.lam@apple.com>
1991
1992         The compiler should always register a structure when it adds its transitionWatchPointSet.
1993         https://bugs.webkit.org/show_bug.cgi?id=178420
1994         <rdar://problem/34814024>
1995
1996         Reviewed by Saam Barati and Filip Pizlo.
1997
1998         Instead of invoking addLazily() to add a structure's transitionWatchpointSet, we
1999         now invoke Graph::registerAndWatchStructureTransition() on the structure.
2000         registerAndWatchStructureTransition() both registers the structure and add its
2001         transitionWatchpointSet to the plan desired watchpoints.
2002
2003         Graph::registerAndWatchStructureTransition() is based on Graph::registerStructure()
2004         except registerAndWatchStructureTransition() adds the structure's
2005         transitionWatchpointSet unconditionally.
2006
2007         * dfg/DFGArgumentsEliminationPhase.cpp:
2008         * dfg/DFGArrayMode.cpp:
2009         (JSC::DFG::ArrayMode::refine const):
2010         * dfg/DFGByteCodeParser.cpp:
2011         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2012         * dfg/DFGFixupPhase.cpp:
2013         (JSC::DFG::FixupPhase::fixupNode):
2014
2015         * dfg/DFGGraph.cpp:
2016         (JSC::DFG::Graph::registerAndWatchStructureTransition):
2017         * dfg/DFGGraph.h:
2018
2019         * dfg/DFGSpeculativeJIT.cpp:
2020         (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
2021         - The second set of addLazily()s is redundant.  This set is executed only when
2022           prototypeChainIsSane is true, and prototypeChainIsSane can only be true if and
2023           only if we've executed the if statement above it.  That preceding if statement
2024           already registerAndWatchStructureTransition() the same 2 structures.  Hence,
2025           this second set can be deleted.
2026
2027         * dfg/DFGWatchpointCollectionPhase.cpp:
2028         (JSC::DFG::WatchpointCollectionPhase::addLazily):
2029         - Deleted an unused function.
2030
2031         * ftl/FTLLowerDFGToB3.cpp:
2032         (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
2033
2034 2017-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>
2035
2036         [JSC] Remove unused private name structure
2037         https://bugs.webkit.org/show_bug.cgi?id=178436
2038
2039         Reviewed by Sam Weinig.
2040
2041         It is no longer used. This patch just removes it.
2042
2043         * runtime/JSGlobalObject.h:
2044         (JSC::JSGlobalObject::numberObjectStructure const):
2045         (JSC::JSGlobalObject::privateNameStructure const): Deleted.
2046
2047 2017-10-18  Ryosuke Niwa  <rniwa@webkit.org>
2048
2049         Fix macOS and iOS builds after r223594.
2050
2051         * JavaScriptCore.xcodeproj/project.pbxproj:
2052
2053 2017-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>
2054
2055         [JSC] __proto__ getter should be fast
2056         https://bugs.webkit.org/show_bug.cgi?id=178067
2057
2058         Reviewed by Saam Barati.
2059
2060         In our ES6 class implementation, we access __proto__ field to retrieve super constructor.
2061         Currently, it is handled as an usual getter call to a generic function. And DFG just emits
2062         Call node for this. It is inefficient since typically we know the `prototype` of the given
2063         object when accessing `object.__proto__` since we emit CheckStructure for this `object`.
2064         If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto,
2065         we can still change this to efficient access to poly proto slot.
2066
2067         This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of
2068         the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant.
2069         ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super
2070         constructor. If we can change this to constant, we can reify CallLinkInfo with this constant.
2071         This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important
2072         for ARES-6 ML.
2073
2074         And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node.
2075
2076         Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling
2077         poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it.
2078         Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too.
2079
2080         This patch improves SixSpeed super.es6 by 3.42x.
2081
2082                                  baseline                  patched
2083
2084         super.es6           123.6666+-3.9917     ^     36.1684+-1.0351        ^ definitely 3.4192x faster
2085
2086         [1]: https://bugs.webkit.org/show_bug.cgi?id=178064
2087
2088         * dfg/DFGAbstractInterpreterInlines.h:
2089         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2090         * dfg/DFGByteCodeParser.cpp:
2091         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2092         (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
2093         (JSC::DFG::ByteCodeParser::handleGetById):
2094         * dfg/DFGClobberize.h:
2095         (JSC::DFG::clobberize):
2096         * dfg/DFGDoesGC.cpp:
2097         (JSC::DFG::doesGC):
2098         * dfg/DFGFixupPhase.cpp:
2099         (JSC::DFG::FixupPhase::fixupNode):
2100         (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
2101         * dfg/DFGHeapLocation.cpp:
2102         (WTF::printInternal):
2103         * dfg/DFGHeapLocation.h:
2104         * dfg/DFGNode.h:
2105         (JSC::DFG::Node::hasHeapPrediction):
2106         (JSC::DFG::Node::shouldSpeculateFunction):
2107         * dfg/DFGNodeType.h:
2108         * dfg/DFGOperations.cpp:
2109         * dfg/DFGOperations.h:
2110         * dfg/DFGPredictionPropagationPhase.cpp:
2111         * dfg/DFGSafeToExecute.h:
2112         (JSC::DFG::safeToExecute):
2113         * dfg/DFGSpeculativeJIT.cpp:
2114         (JSC::DFG::SpeculativeJIT::speculateFunction):
2115         (JSC::DFG::SpeculativeJIT::speculateFinalObject):
2116         (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
2117         * dfg/DFGSpeculativeJIT.h:
2118         (JSC::DFG::SpeculativeJIT::callOperation):
2119         * dfg/DFGSpeculativeJIT32_64.cpp:
2120         (JSC::DFG::SpeculativeJIT::compile):
2121         * dfg/DFGSpeculativeJIT64.cpp:
2122         (JSC::DFG::SpeculativeJIT::compile):
2123         * ftl/FTLCapabilities.cpp:
2124         (JSC::FTL::canCompile):
2125         * ftl/FTLLowerDFGToB3.cpp:
2126         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2127         (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
2128         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
2129         * jit/IntrinsicEmitter.cpp:
2130         (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
2131         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
2132         * jit/JITOperations.h:
2133         * runtime/Intrinsic.cpp:
2134         (JSC::intrinsicName):
2135         * runtime/Intrinsic.h:
2136         * runtime/JSGlobalObject.cpp:
2137         (JSC::JSGlobalObject::init):
2138         * runtime/JSGlobalObject.h:
2139         (JSC::JSGlobalObject::booleanPrototype const):
2140         (JSC::JSGlobalObject::numberPrototype const):
2141         (JSC::JSGlobalObject::booleanObjectStructure const):
2142         * runtime/JSGlobalObjectFunctions.cpp:
2143         (JSC::globalFuncProtoGetter):
2144         * runtime/JSGlobalObjectFunctions.h:
2145         * runtime/ObjectConstructor.cpp:
2146         * runtime/ReflectObject.cpp:
2147
2148 2017-10-17  Ryan Haddad  <ryanhaddad@apple.com>
2149
2150         Unreviewed, rolling out r223523.
2151
2152         A test for this change is failing on debug JSC bots.
2153
2154         Reverted changeset:
2155
2156         "[JSC] __proto__ getter should be fast"
2157         https://bugs.webkit.org/show_bug.cgi?id=178067
2158         https://trac.webkit.org/changeset/223523
2159
2160 2017-10-17  Youenn Fablet  <youenn@apple.com>
2161
2162         Add preliminary support for fetch event
2163         https://bugs.webkit.org/show_bug.cgi?id=178171
2164
2165         Reviewed by Chris Dumez.
2166
2167         Adding events
2168
2169         * runtime/JSPromise.h:
2170
2171 2017-10-10  Yusuke Suzuki  <utatane.tea@gmail.com>
2172
2173         [JSC] __proto__ getter should be fast
2174         https://bugs.webkit.org/show_bug.cgi?id=178067
2175
2176         Reviewed by Saam Barati.
2177
2178         In our ES6 class implementation, we access __proto__ field to retrieve super constructor.
2179         Currently, it is handled as an usual getter call to a generic function. And DFG just emits
2180         Call node for this. It is inefficient since typically we know the `prototype` of the given
2181         object when accessing `object.__proto__` since we emit CheckStructure for this `object`.
2182         If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto,
2183         we can still change this to efficient access to poly proto slot.
2184
2185         This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of
2186         the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant.
2187         ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super
2188         constructor. If we can change this to constant, we can reify CallLinkInfo with this constant.
2189         This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important
2190         for ARES-6 ML.
2191
2192         And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node.
2193
2194         Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling
2195         poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it.
2196         Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too.
2197
2198         This patch improves SixSpeed super.es6 by 3.42x.
2199
2200                                  baseline                  patched
2201
2202         super.es6           123.6666+-3.9917     ^     36.1684+-1.0351        ^ definitely 3.4192x faster
2203
2204         [1]: https://bugs.webkit.org/show_bug.cgi?id=178064
2205
2206         * dfg/DFGAbstractInterpreterInlines.h:
2207         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2208         * dfg/DFGByteCodeParser.cpp:
2209         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2210         (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
2211         (JSC::DFG::ByteCodeParser::handleGetById):
2212         * dfg/DFGClobberize.h:
2213         (JSC::DFG::clobberize):
2214         * dfg/DFGDoesGC.cpp:
2215         (JSC::DFG::doesGC):
2216         * dfg/DFGFixupPhase.cpp:
2217         (JSC::DFG::FixupPhase::fixupNode):
2218         (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
2219         * dfg/DFGHeapLocation.cpp:
2220         (WTF::printInternal):
2221         * dfg/DFGHeapLocation.h:
2222         * dfg/DFGNode.h:
2223         (JSC::DFG::Node::hasHeapPrediction):
2224         (JSC::DFG::Node::shouldSpeculateFunction):
2225         * dfg/DFGNodeType.h:
2226         * dfg/DFGOperations.cpp:
2227         * dfg/DFGOperations.h:
2228         * dfg/DFGPredictionPropagationPhase.cpp:
2229         * dfg/DFGSafeToExecute.h:
2230         (JSC::DFG::safeToExecute):
2231         * dfg/DFGSpeculativeJIT.cpp:
2232         (JSC::DFG::SpeculativeJIT::speculateFunction):
2233         (JSC::DFG::SpeculativeJIT::speculateFinalObject):
2234         (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
2235         * dfg/DFGSpeculativeJIT.h:
2236         * dfg/DFGSpeculativeJIT32_64.cpp:
2237         (JSC::DFG::SpeculativeJIT::compile):
2238         * dfg/DFGSpeculativeJIT64.cpp:
2239         (JSC::DFG::SpeculativeJIT::compile):
2240         * ftl/FTLCapabilities.cpp:
2241         (JSC::FTL::canCompile):
2242         * ftl/FTLLowerDFGToB3.cpp:
2243         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2244         (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
2245         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
2246         * jit/IntrinsicEmitter.cpp:
2247         (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
2248         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
2249         * runtime/Intrinsic.cpp:
2250         (JSC::intrinsicName):
2251         * runtime/Intrinsic.h:
2252         * runtime/JSGlobalObject.cpp:
2253         (JSC::JSGlobalObject::init):
2254         * runtime/JSGlobalObjectFunctions.cpp:
2255         (JSC::globalFuncProtoGetter):
2256         * runtime/JSGlobalObjectFunctions.h:
2257         * runtime/ObjectConstructor.cpp:
2258         * runtime/ReflectObject.cpp:
2259
2260 2017-10-17  Keith Miller  <keith_miller@apple.com>
2261
2262         Change WebCore sources to work with unified source builds
2263         https://bugs.webkit.org/show_bug.cgi?id=178229
2264
2265         Rubber stamped by Tim Horton.
2266
2267         * Configurations/FeatureDefines.xcconfig:
2268
2269 2017-10-15  Filip Pizlo  <fpizlo@apple.com>
2270
2271         Make some asserts into release asserts
2272         https://bugs.webkit.org/show_bug.cgi?id=178324
2273
2274         Reviewed by Saam Barati.
2275         
2276         These asserts are not on perf critical paths, so they might as well be release asserts.
2277
2278         * runtime/DataView.h:
2279         (JSC::DataView::get):
2280         (JSC::DataView::set):
2281
2282 2017-10-16  JF Bastien  <jfbastien@apple.com>
2283
2284         JSRunLoopTimer: reduce likely race when used improperly
2285         https://bugs.webkit.org/show_bug.cgi?id=178298
2286         <rdar://problem/32899816>
2287
2288         Reviewed by Saam Barati.
2289
2290         If an API user sets a timer on JSRunLoopTimer, and then racily
2291         destroys the JSRunLoopTimer while the timer is firing then it's
2292         possible for timerDidFire to cause a use-after-free and / or crash
2293         because e.g. m_apiLock becomes a nullptr while timerDidFire is
2294         executing. That results from an invalid use of JSRunLoopTimer, but
2295         we should try to be more resilient for that type of misuse because
2296         it's not necessarily easy to catch by inspection.
2297
2298         With this change the only remaining race is if the timer fires,
2299         and then only timerDidFire's prologue executes, but not the load
2300         of the m_apiLock pointer from `this`. It's a much smaller race.
2301
2302         Separately, I'll reach out to API users who are seemingly misusing
2303         the API.
2304
2305         * runtime/JSRunLoopTimer.cpp:
2306         (JSC::JSRunLoopTimer::timerDidFire): put m_apiLock on the stack,
2307         and checks for nullptr. This prevents loading it twice off of
2308         `this` and turns a nullptr deref into "just" a use-after-free.
2309         (JSC::JSRunLoopTimer::~JSRunLoopTimer): acquire m_apiLock before
2310         calling m_vm->unregisterRunLoopTimer(this), which in turn does
2311         CFRunLoopRemoveTimer / CFRunLoopTimerInvalidate. This prevents
2312         timerDidFire from doing much while the timers are un-registered.
2313         ~JSRunLoopTimer also needs to set m_apiLock to nullptr before
2314         releasing the lock, so it needs its own local copy.
2315
2316 2017-10-15  Yusuke Suzuki  <utatane.tea@gmail.com>
2317
2318         [JSC] Perform module specifier validation at parsing time
2319         https://bugs.webkit.org/show_bug.cgi?id=178256
2320
2321         Reviewed by Darin Adler.
2322
2323         This patch make module loader's `resolve` operation synchronous. And we validate
2324         module's requested module names when instantiating the module instead of satisfying
2325         module's dependencies. This change is not observable to users. But this is precise
2326         to the spec and this optimizes & simplifies the current module loader a bit by
2327         reducing object allocations.
2328
2329         Previously, we have an object called pair in the module loader. This is pair of
2330         module's name and module's record. And we use it to link one module to dependent
2331         modules. Now, it is replaced with module's registry entry.
2332
2333         We also change our loader functions to take a registry entry instead of a module key.
2334         Previous design is due to the consideration that these APIs may be exposed to users
2335         in whatwg/loader spec. However, this won't happen. This change removes unnecessary
2336         repeatedly hash map lookups.
2337
2338         * builtins/ModuleLoaderPrototype.js:
2339         (globalPrivate.newRegistryEntry):
2340         (requestFetch):
2341         (requestInstantiate):
2342         (requestSatisfy):
2343         (link):
2344         (moduleEvaluation):
2345         (loadModule):
2346         * jsc.cpp:
2347         (GlobalObject::moduleLoaderResolve):
2348         * runtime/AbstractModuleRecord.cpp:
2349         (JSC::AbstractModuleRecord::finishCreation):
2350         (JSC::AbstractModuleRecord::hostResolveImportedModule):
2351         * runtime/JSGlobalObject.h:
2352         * runtime/JSModuleLoader.cpp:
2353         (JSC::JSModuleLoader::resolveSync):
2354         (JSC::JSModuleLoader::resolve):
2355         * runtime/JSModuleLoader.h:
2356         * runtime/ModuleLoaderPrototype.cpp:
2357         (JSC::moduleLoaderPrototypeResolveSync):
2358
2359 2017-10-14  Devin Rousso  <webkit@devinrousso.com>
2360
2361         Web Inspector: provide a way to enable/disable event listeners
2362         https://bugs.webkit.org/show_bug.cgi?id=177451
2363
2364         Reviewed by Joseph Pecoraro.
2365
2366         * inspector/protocol/DOM.json:
2367         Add `setEventListenerDisabled` command that enables/disables a specific event listener
2368         during event dispatch. When a disabled event listener is fired, the listener's callback will
2369         not be called.
2370
2371 2017-10-14  Yusuke Suzuki  <utatane.tea@gmail.com>
2372
2373         Reland "Add Above/Below comparisons for UInt32 patterns"
2374         https://bugs.webkit.org/show_bug.cgi?id=177281
2375
2376         Reviewed by Saam Barati.
2377
2378         We reland this patch without DFGStrengthReduction change to see what causes
2379         regression in the iOS bot.
2380
2381         Sometimes, we would like to have UInt32 operations in JS. While VM does
2382         not support UInt32 nicely, VM supports efficient Int32 operations. As long
2383         as signedness does not matter, we can just perform Int32 operations instead
2384         and recognize its bit pattern as UInt32.
2385
2386         But of course, some operations respect signedness. The most frequently
2387         used one is comparison. Octane/zlib performs UInt32 comparison by performing
2388         `val >>> 0`. It emits op_urshift and op_unsigned. op_urshift produces
2389         UInt32 in Int32 form. And op_unsigned will generate Double value if
2390         the generated Int32 is < 0 (which should be UInt32).
2391
2392         There is a chance for optimization. The given code pattern is the following.
2393
2394             op_unsigned(op_urshift(@1)) lessThan:< op_unsigned(op_urshift(@2))
2395
2396         This can be converted to the following.
2397
2398             op_urshift(@1) below:< op_urshift(@2)
2399
2400         The above conversion is nice since
2401
2402         1. We can avoid op_unsigned. This could be unsignedness check in DFG. Since
2403         this check depends on the value of Int32, dropping this check is not as easy as
2404         removing Int32 edge filters.
2405
2406         2. We can perform unsigned comparison in Int32 form. We do not need to convert
2407         them to DoubleRep.
2408
2409         Since the above comparison exists in Octane/zlib's *super* hot path, dropping
2410         op_unsigned offers huge win.
2411
2412         At first, my patch attempts to convert the above thing in DFG pipeline.
2413         However it poses several problems.
2414
2415         1. MovHint is not well removed. It makes UInt32ToNumber (which is for op_unsigned) live.
2416         2. UInt32ToNumber could cause an OSR exit. So if we have the following nodes,
2417
2418             2: UInt32ToNumber(@0)
2419             3: MovHint(@2, xxx)
2420             4: UInt32ToNumber(@1)
2421             5: MovHint(@1, xxx)
2422
2423         we could drop @5's MovHint. But @3 is difficult since @4 can exit.
2424
2425         So, instead, we start introducing a simple optimization in the bytecode compiler.
2426         It performs pattern matching for op_urshift and comparison to drop op_unsigned.
2427         We adds op_below and op_above families to bytecodes. They only accept Int32 and
2428         perform unsigned comparison.
2429
2430         This offers 4% performance improvement in Octane/zlib.
2431
2432                                     baseline                  patched
2433
2434         zlib           x2     431.07483+-16.28434       414.33407+-9.38375         might be 1.0404x faster
2435
2436         * bytecode/BytecodeDumper.cpp:
2437         (JSC::BytecodeDumper<Block>::printCompareJump):
2438         (JSC::BytecodeDumper<Block>::dumpBytecode):
2439         * bytecode/BytecodeDumper.h:
2440         * bytecode/BytecodeList.json:
2441         * bytecode/BytecodeUseDef.h:
2442         (JSC::computeUsesForBytecodeOffset):
2443         (JSC::computeDefsForBytecodeOffset):
2444         * bytecode/Opcode.h:
2445         (JSC::isBranch):
2446         * bytecode/PreciseJumpTargetsInlines.h:
2447         (JSC::extractStoredJumpTargetsForBytecodeOffset):
2448         * bytecompiler/BytecodeGenerator.cpp:
2449         (JSC::BytecodeGenerator::emitJumpIfTrue):
2450         (JSC::BytecodeGenerator::emitJumpIfFalse):
2451         * bytecompiler/NodesCodegen.cpp:
2452         (JSC::BinaryOpNode::emitBytecode):
2453         * dfg/DFGAbstractInterpreterInlines.h:
2454         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2455         * dfg/DFGByteCodeParser.cpp:
2456         (JSC::DFG::ByteCodeParser::parseBlock):
2457         * dfg/DFGCapabilities.cpp:
2458         (JSC::DFG::capabilityLevel):
2459         * dfg/DFGClobberize.h:
2460         (JSC::DFG::clobberize):
2461         * dfg/DFGDoesGC.cpp:
2462         (JSC::DFG::doesGC):
2463         * dfg/DFGFixupPhase.cpp:
2464         (JSC::DFG::FixupPhase::fixupNode):
2465         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
2466         * dfg/DFGNodeType.h:
2467         * dfg/DFGPredictionPropagationPhase.cpp:
2468         * dfg/DFGSafeToExecute.h:
2469         (JSC::DFG::safeToExecute):
2470         * dfg/DFGSpeculativeJIT.cpp:
2471         (JSC::DFG::SpeculativeJIT::compileCompareUnsigned):
2472         * dfg/DFGSpeculativeJIT.h:
2473         * dfg/DFGSpeculativeJIT32_64.cpp:
2474         (JSC::DFG::SpeculativeJIT::compile):
2475         * dfg/DFGSpeculativeJIT64.cpp:
2476         (JSC::DFG::SpeculativeJIT::compile):
2477         * dfg/DFGValidate.cpp:
2478         * ftl/FTLCapabilities.cpp:
2479         (JSC::FTL::canCompile):
2480         * ftl/FTLLowerDFGToB3.cpp:
2481         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2482         (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelow):
2483         (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelowEq):
2484         * jit/JIT.cpp:
2485         (JSC::JIT::privateCompileMainPass):
2486         * jit/JIT.h:
2487         * jit/JITArithmetic.cpp:
2488         (JSC::JIT::emit_op_below):
2489         (JSC::JIT::emit_op_beloweq):
2490         (JSC::JIT::emit_op_jbelow):
2491         (JSC::JIT::emit_op_jbeloweq):
2492         (JSC::JIT::emit_compareUnsignedAndJump):
2493         (JSC::JIT::emit_compareUnsigned):
2494         * jit/JITArithmetic32_64.cpp:
2495         (JSC::JIT::emit_compareUnsignedAndJump):
2496         (JSC::JIT::emit_compareUnsigned):
2497         * llint/LowLevelInterpreter.asm:
2498         * llint/LowLevelInterpreter32_64.asm:
2499         * llint/LowLevelInterpreter64.asm:
2500         * parser/Nodes.h:
2501         (JSC::ExpressionNode::isBinaryOpNode const):
2502
2503 2017-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
2504
2505         WebAssembly: Wasm functions should have either JSFunctionType or TypeOfShouldCallGetCallData
2506         https://bugs.webkit.org/show_bug.cgi?id=178210
2507
2508         Reviewed by Saam Barati.
2509
2510         In Wasm, we have two JS functions exposed to users: WebAssemblyFunction and WebAssemblyWrapperFunction.
2511         The former is an exported wasm function and the latter is an imported & exported function. Since they
2512         have [[Call]], they should be categorized into "function" in typeof operation.
2513
2514         However, these functions do not implement our function protocol correctly. They inherit JSFunction.
2515         But JSType of WebAssemblyFunction is WebAssemblyFunctionType, and one of WebAssemblyWrapperFunction is
2516         ObjectType. Since both do not have TypeOfShouldCallGetCallData, they return "object" when performing
2517         typeof operation.
2518
2519         In this patch, we address the above issue by the following 2 fixes.
2520
2521         1. We add TypeOfShouldCallGetCallData to WebAssemblyFunction. This is the same way how we implement
2522         InternalFunction. Since WebAssemblyFunction requires WebAssemblyFunctionType for fast checking in Wasm
2523         implementation, we cannot make this JSFunctionType.
2524
2525         2. On the other hand, WebAssemblyWrapperFunction does not require a specific JSType. So this patch
2526         changes JSType of WebAssemblyWrapperFunction to JSFunctionType. JSFunctionType can be usable for derived
2527         classes of JSFunction (e.g. JSCustomGetterSetterFunction).
2528
2529         * wasm/js/WebAssemblyFunction.h:
2530         (JSC::WebAssemblyFunction::signatureIndex const): Deleted.
2531         (JSC::WebAssemblyFunction::wasmEntrypointLoadLocation const): Deleted.
2532         (JSC::WebAssemblyFunction::callableFunction const): Deleted.
2533         (JSC::WebAssemblyFunction::jsEntrypoint): Deleted.
2534         (JSC::WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation): Deleted.
2535         * wasm/js/WebAssemblyWrapperFunction.cpp:
2536         (JSC::WebAssemblyWrapperFunction::createStructure):
2537         * wasm/js/WebAssemblyWrapperFunction.h:
2538         (JSC::WebAssemblyWrapperFunction::signatureIndex const): Deleted.
2539         (JSC::WebAssemblyWrapperFunction::wasmEntrypointLoadLocation const): Deleted.
2540         (JSC::WebAssemblyWrapperFunction::callableFunction const): Deleted.
2541         (JSC::WebAssemblyWrapperFunction::function): Deleted.
2542
2543 2017-10-12  Per Arne Vollan  <pvollan@apple.com>
2544
2545         [Win64] JSC compile error.
2546         https://bugs.webkit.org/show_bug.cgi?id=178213
2547
2548         Reviewed by Alex Christensen.
2549
2550         Add static cast from int64 to uintptr_t.
2551
2552         * dfg/DFGOSRExit.cpp:
2553         (JSC::DFG::OSRExit::executeOSRExit):
2554
2555 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
2556
2557         Enable gigacage on iOS
2558         https://bugs.webkit.org/show_bug.cgi?id=177586
2559
2560         Reviewed by JF Bastien.
2561
2562         The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
2563         executing JS, so the LLInt needs to know how to load from global variables on all platforms that
2564         have Gigacage. So, this teaches ARM64 how to load from global variables.
2565         
2566         Also, this makes the code handle disabling the gigacage a bit better.
2567
2568         * ftl/FTLLowerDFGToB3.cpp:
2569         (JSC::FTL::DFG::LowerDFGToB3::caged):
2570         * jit/AssemblyHelpers.h:
2571         (JSC::AssemblyHelpers::cage):
2572         (JSC::AssemblyHelpers::cageConditionally):
2573         * offlineasm/arm64.rb:
2574         * offlineasm/asm.rb:
2575         * offlineasm/instructions.rb:
2576
2577 2017-10-11  Sam Weinig  <sam@webkit.org>
2578
2579         Remove out-parameter variants of copyToVector
2580         https://bugs.webkit.org/show_bug.cgi?id=178155
2581
2582         Reviewed by Tim Horton.
2583
2584         * inspector/ScriptDebugServer.cpp:
2585         (Inspector::ScriptDebugServer::dispatchBreakpointActionLog):
2586         (Inspector::ScriptDebugServer::dispatchBreakpointActionSound):
2587         (Inspector::ScriptDebugServer::dispatchBreakpointActionProbe):
2588         (Inspector::ScriptDebugServer::dispatchDidParseSource):
2589         (Inspector::ScriptDebugServer::dispatchFailedToParseSource):
2590         (Inspector::ScriptDebugServer::dispatchFunctionToListeners):
2591             
2592             Replace out-parameter based copyToVector, with one that returns a Vector.
2593
2594 2017-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
2595
2596         Support integrity="" on module scripts
2597         https://bugs.webkit.org/show_bug.cgi?id=177959
2598
2599         Reviewed by Sam Weinig.
2600
2601         This patch adds Subresource Integrity check for module scripts. Currently,
2602         only top-level module can be verified with integrity parameter since there
2603         is no way to perform integrity check onto the imported modules.
2604
2605         In JSC side, we add `parameters` to the entry point of the module loader
2606         pipeline. This is fetching parameters and used when fetching modules.
2607
2608         We separately pass this parameters to the pipeline along with the script fetcher.
2609         The script fetcher is only one for module graph since this is the initiator of
2610         this module graph loading. On the other hand, this parameters is for each
2611         module fetching. While setting "integrity" parameters to this script fetcher is
2612         sufficient to pass parameters to top-level-module's fetching, it is not enough
2613         for the future extension.
2614
2615         In the future, we will investigate a way to pass parameters to each non-top-level
2616         module. At that time, this `parameters` should be per-module. This is because
2617         "integrity" value should be different for each module. For example, we will accept
2618         some form of syntax to add parameters to `import`. Some proposed syntax is like
2619         https://discourse.wicg.io/t/specifying-nonce-or-integrity-when-importing-modules/1861
2620
2621         import "./xxx.js" integrity "xxxxxxx"
2622
2623         In this case, this `parameters` will be passed to "./xxx.js" module fetching. This
2624         `parameters` should be different from the one of top-level-module's one. That's why
2625         we need per-module `parameters` and why this patch adds `parameters` to the module pipeline.
2626
2627         On the other hand, we also want to keep script fetcher. This `per-module-graph` thing
2628         is important to offer module-graph-wide information. For example, import.meta would
2629         have `import.meta.scriptElement`, which is the script element fetching the module graph
2630         including this. So, we keep the both, script fetcher and parameters.
2631         https://github.com/tc39/proposal-import-meta
2632
2633         This parameters will be finally used by pipeline's fetch hook, and WebCore side
2634         can use this parameters to fetch modules.
2635
2636         We also further clean up the module pipeline by dropping unnecessary features.
2637
2638         * JavaScriptCore.xcodeproj/project.pbxproj:
2639         * Sources.txt:
2640         * builtins/ModuleLoaderPrototype.js:
2641         (requestFetch):
2642         (requestInstantiate):
2643         (requestSatisfy):
2644         (loadModule):
2645         (loadAndEvaluateModule):
2646         This loadAndEvaluateModule should be implemented by just calling loadModule and
2647         linkAndEvaluateModule. We can drop requestReady and requestLink.
2648
2649         (requestLink): Deleted.
2650         (requestImportModule): Deleted.
2651         * jsc.cpp:
2652         (GlobalObject::moduleLoaderImportModule):
2653         (GlobalObject::moduleLoaderFetch):
2654         import and fetch hook takes parameters. Currently, we always pass `undefined` for
2655         import hook. When dynamic `import()` is extended to accept additional parameters
2656         like integrity, this parameters will be replaced with the actual value.
2657
2658         (functionLoadModule):
2659         (runWithOptions):
2660         * runtime/Completion.cpp:
2661         (JSC::loadAndEvaluateModule):
2662         (JSC::loadModule):
2663         (JSC::importModule):
2664         * runtime/Completion.h:
2665         * runtime/JSGlobalObject.h:
2666         * runtime/JSGlobalObjectFunctions.cpp:
2667         (JSC::globalFuncImportModule):
2668         * runtime/JSModuleLoader.cpp:
2669         (JSC::JSModuleLoader::loadAndEvaluateModule):
2670         (JSC::JSModuleLoader::loadModule):
2671         (JSC::JSModuleLoader::requestImportModule):
2672         (JSC::JSModuleLoader::importModule):
2673         (JSC::JSModuleLoader::fetch):
2674         * runtime/JSModuleLoader.h:
2675         * runtime/JSScriptFetchParameters.cpp: Added.
2676         (JSC::JSScriptFetchParameters::destroy):
2677         * runtime/JSScriptFetchParameters.h: Added.
2678         (JSC::JSScriptFetchParameters::createStructure):
2679         (JSC::JSScriptFetchParameters::create):
2680         (JSC::JSScriptFetchParameters::parameters const):
2681         (JSC::JSScriptFetchParameters::JSScriptFetchParameters):
2682         Add ScriptFetchParameters' JSCell wrapper, JSScriptFetchParameters.
2683         It is used in the module pipeline.
2684
2685         * runtime/JSType.h:
2686         * runtime/ModuleLoaderPrototype.cpp:
2687         (JSC::moduleLoaderPrototypeFetch):
2688         * runtime/ScriptFetchParameters.h: Added.
2689         (JSC::ScriptFetchParameters::~ScriptFetchParameters):
2690         Add ScriptFetchParameters. We can define our own custom ScriptFetchParameters
2691         by inheriting this class. WebCore creates ModuleFetchParameters by inheriting
2692         this.
2693
2694         * runtime/VM.cpp:
2695         (JSC::VM::VM):
2696         * runtime/VM.h:
2697
2698 2017-10-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2699
2700         import.meta should not be assignable
2701         https://bugs.webkit.org/show_bug.cgi?id=178202
2702
2703         Reviewed by Saam Barati.
2704
2705         `import.meta` cannot be used for LHS. This patch adds MetaPropertyNode
2706         and make NewTargetNode and ImportMetaNode as derived classes of MetaPropertyNode.
2707         We change the parser not to allow assignments for MetaPropertyNode.
2708
2709         * bytecompiler/NodesCodegen.cpp:
2710         (JSC::ImportMetaNode::emitBytecode):
2711         * parser/ASTBuilder.h:
2712         (JSC::ASTBuilder::createImportMetaExpr):
2713         (JSC::ASTBuilder::isMetaProperty):
2714         (JSC::ASTBuilder::isImportMeta):
2715         * parser/NodeConstructors.h:
2716         (JSC::MetaPropertyNode::MetaPropertyNode):
2717         (JSC::NewTargetNode::NewTargetNode):
2718         (JSC::ImportMetaNode::ImportMetaNode):
2719         * parser/Nodes.h:
2720         (JSC::ExpressionNode::isMetaProperty const):
2721         (JSC::ExpressionNode::isImportMeta const):
2722         * parser/Parser.cpp:
2723         (JSC::Parser<LexerType>::metaPropertyName):
2724         (JSC::Parser<LexerType>::parseAssignmentExpression):
2725         (JSC::Parser<LexerType>::parseMemberExpression):
2726         (JSC::Parser<LexerType>::parseUnaryExpression):
2727         * parser/Parser.h:
2728         * parser/SyntaxChecker.h:
2729         (JSC::SyntaxChecker::createImportMetaExpr):
2730         (JSC::SyntaxChecker::isMetaProperty):
2731         (JSC::SyntaxChecker::isImportMeta):
2732
2733 2017-10-11  Saam Barati  <sbarati@apple.com>
2734
2735         Runtime disable poly proto because it may be a 3-4% Speedometer regression
2736         https://bugs.webkit.org/show_bug.cgi?id=178192
2737
2738         Reviewed by JF Bastien.
2739
2740         * runtime/Options.h:
2741         * runtime/StructureInlines.h:
2742         (JSC::Structure::shouldConvertToPolyProto):
2743
2744 2017-10-11  Commit Queue  <commit-queue@webkit.org>
2745
2746         Unreviewed, rolling out r223113 and r223121.
2747         https://bugs.webkit.org/show_bug.cgi?id=178182
2748
2749         Reintroduced 20% regression on Kraken (Requested by rniwa on
2750         #webkit).
2751
2752         Reverted changesets:
2753
2754         "Enable gigacage on iOS"
2755         https://bugs.webkit.org/show_bug.cgi?id=177586
2756         https://trac.webkit.org/changeset/223113
2757
2758         "Use one virtual allocation for all gigacages and their
2759         runways"
2760         https://bugs.webkit.org/show_bug.cgi?id=178050
2761         https://trac.webkit.org/changeset/223121
2762
2763 2017-10-11  Michael Saboff  <msaboff@apple.com>
2764
2765         Update JavaScriptCore/ucd/CaseFolding.txt to Unicode database 10.0
2766         https://bugs.webkit.org/show_bug.cgi?id=178106
2767
2768         Reviewed by Keith Miller.
2769
2770         * ucd/CaseFolding.txt:
2771
2772 2017-10-11  Caio Lima  <ticaiolima@gmail.com>
2773
2774         Object properties are undefined in super.call() but not in this.call()
2775         https://bugs.webkit.org/show_bug.cgi?id=177230
2776
2777         Reviewed by Saam Barati.
2778
2779         Bytecode generation for "super.call(...)" or "super.apply(...)"
2780         shouldn't be considered as CallFunctionCallDotNode or
2781         ApplyFunctionCallDotNode because they should be considered as common
2782         super property access as any other function. According to spec[1],
2783         "super" is not refering to parent constructor.
2784
2785         [1] - https://tc39.github.io/ecma262/#sec-super-keyword-runtime-semantics-evaluation
2786
2787         * parser/ASTBuilder.h:
2788         (JSC::ASTBuilder::makeFunctionCallNode):
2789         * parser/Parser.cpp:
2790         (JSC::Parser<LexerType>::parseMemberExpression):
2791         * parser/SyntaxChecker.h:
2792         (JSC::SyntaxChecker::makeFunctionCallNode):
2793
2794 2017-10-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2795
2796         [JSC] Drop Instantiate hook in ES6 module loader
2797         https://bugs.webkit.org/show_bug.cgi?id=178162
2798
2799         Reviewed by Sam Weinig.
2800
2801         This patch is a part of patch series for module loader refactoring to adopt
2802         integrity="" parameters and introduce new whatwg module import mechanism.
2803
2804         In this patch, we drop instantiate hook in module loader. This hook is originally
2805         introduced because it is defined in whatwg/loader spec. But this hook is not
2806         used in our implementation, and this hook won't be used since (1) whatwg/loader
2807         spec is abandoned, and (2) this type of hooks should be done in Service Workers.
2808
2809         In addition, this patch applies some cleaning up of our module loader JS code
2810         to simplify things. This change paves the way to more efficient loader implementation
2811         with great flexibility to adopt integrity="" parameters.
2812
2813         * builtins/ModuleLoaderPrototype.js:
2814         (requestInstantiate):
2815         (provideFetch):
2816         provide is changed to provideFetch since we only used this function with Fetch stage parameter.
2817
2818         (fulfillInstantiate): Deleted.
2819         (commitInstantiated): Deleted.
2820         (instantiation): Deleted.
2821         They are merged into requestInstantiate code. This is simpler.
2822
2823         (provide): Deleted.
2824         * jsc.cpp:
2825         * runtime/Completion.cpp:
2826         (JSC::loadAndEvaluateModule):
2827         (JSC::loadModule):
2828         * runtime/JSGlobalObject.cpp:
2829         * runtime/JSGlobalObject.h:
2830         * runtime/JSModuleLoader.cpp:
2831         (JSC::JSModuleLoader::provideFetch):
2832         (JSC::JSModuleLoader::provide): Deleted.
2833         Changed to provideFetch.
2834
2835         (JSC::JSModuleLoader::instantiate): Deleted.
2836         Drop this hook.
2837
2838         * runtime/JSModuleLoader.h:
2839         * runtime/ModuleLoaderPrototype.cpp:
2840         (JSC::moduleLoaderPrototypeInstantiate): Deleted.
2841         Drop this hook.
2842
2843 2017-10-10  Saam Barati  <sbarati@apple.com>
2844
2845         Prototype structure transition should be a deferred transition
2846         https://bugs.webkit.org/show_bug.cgi?id=177734
2847
2848         Reviewed by Keith Miller.
2849
2850         Absence ObjectPropertyConditions work by verifying both that the Structure 
2851         does not have a particular property and that its prototype has
2852         remained constant. However, the prototype transition was firing
2853         the transition watchpoint before setting the object's structure.
2854         This meant that isValid for Absence would never return false because
2855         the prototype changed. Clearly this is wrong. The reason this didn't
2856         break OPCs in general is that we'd also check if we could still watch
2857         the OPC. In this case, we can't still watch it because we're inspecting
2858         a structure with an invalidated transition watchpoint. To fix
2859         this weird quirk of the code, I'm making it so that doing a prototype
2860         transition uses the DeferredStructureTransitionWatchpointFire machinery.
2861         
2862         This patch also fixes some dead code that I left in regarding
2863         poly proto in OPC.
2864
2865         * bytecode/PropertyCondition.cpp:
2866         (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
2867         * runtime/JSObject.cpp:
2868         (JSC::JSObject::setPrototypeDirect):
2869         * runtime/Structure.cpp:
2870         (JSC::Structure::changePrototypeTransition):
2871         * runtime/Structure.h:
2872
2873 2017-10-10  Robin Morisset  <rmorisset@apple.com>
2874
2875         Avoid allocating useless landingBlocks in DFGByteCodeParser::handleInlining()
2876         https://bugs.webkit.org/show_bug.cgi?id=177926
2877
2878         Reviewed by Saam Barati.
2879
2880         When doing polyvariant inlining, there used to be a landing block for each callee, each of which was then linked to a continuation block.
2881         With this change, we allocate the continuation block first, and pass it to the inlining routine so that op_ret in the callee link directly to it.
2882         The only subtlety is that when inlining an intrinsic we must do the jump by hand, and also remember to call processSetLocalQueue with nextOffset before it.
2883
2884         * dfg/DFGByteCodeParser.cpp:
2885         (JSC::DFG::ByteCodeParser::inlineCall):
2886         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
2887         (JSC::DFG::ByteCodeParser::handleInlining):
2888         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
2889         (JSC::DFG::ByteCodeParser::parse):
2890
2891 2017-10-10  Guillaume Emont  <guijemont@igalia.com>
2892
2893         Fix compilation when MASM_PROBE (and therefore DFG) are disabled
2894         https://bugs.webkit.org/show_bug.cgi?id=178134
2895
2896         Reviewed by Saam Barati.
2897
2898         * bytecode/CodeBlock.cpp:
2899         * bytecode/CodeBlock.h:
2900         Disable some code when building without DFG_JIT.
2901
2902 2017-10-10  Sam Weinig  <sam@webkit.org>
2903
2904         Replace copyKeysToVector/copyValuesToVector with copyToVector(map.keys())/copyToVector(map.values())
2905         https://bugs.webkit.org/show_bug.cgi?id=178102
2906
2907         Reviewed by Tim Horton.
2908
2909         * inspector/agents/InspectorDebuggerAgent.cpp:
2910         (Inspector::InspectorDebuggerAgent::clearInspectorBreakpointState):
2911
2912 2017-10-10  Michael Saboff  <msaboff@apple.com>
2913
2914         Unreviewed build fix.
2915
2916         Removed unused lambda capture.
2917
2918         * yarr/YarrPattern.cpp:
2919         (JSC::Yarr::CharacterClassConstructor::appendInverted):
2920
2921 2017-10-10  Saam Barati  <sbarati@apple.com>
2922
2923         The prototype cache should be aware of the Executable it generates a Structure for
2924         https://bugs.webkit.org/show_bug.cgi?id=177907
2925
2926         Reviewed by Filip Pizlo.
2927
2928         This patch renames PrototypeMap to StructureCache because
2929         it is no longer a map of the prototypes in the VM. It's
2930         only used to cache Structures during object construction.
2931         
2932         The main change of this patch is to guarantee that Structures generated
2933         by the create_this originating from different two different Executables'
2934         bytecode won't hash-cons to the same thing. Previously, we could hash-cons
2935         them depending on the JSObject* prototype pointer. This would cause the last
2936         thing that hash-consed to overwrite the Structure's poly proto watchpoint. This
2937         happened because when we initialize a JSFunction's ObjectAllocationProfile,
2938         we set the resulting Structure's poly proto watchpoint. This could cause a Structure
2939         generating from some Executable e1 to end up with the poly proto watchpoint
2940         for another Executable e2 simply because JSFunctions backed by e1 and e2
2941         shared the same prototype. Then, based on profiling information, we may fire the
2942         wrong Executable's poly proto watchpoint. This patch fixes this bug by
2943         guaranteeing that Structures generating from create_this for different
2944         Executables are unique even if they share the same prototype by adding
2945         the FunctionExecutable* as another field in PrototypeKey.
2946
2947         * JavaScriptCore.xcodeproj/project.pbxproj:
2948         * Sources.txt:
2949         * bytecode/InternalFunctionAllocationProfile.h:
2950         (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
2951         * bytecode/ObjectAllocationProfile.cpp:
2952         (JSC::ObjectAllocationProfile::initializeProfile):
2953         * dfg/DFGOperations.cpp:
2954         * runtime/CommonSlowPaths.cpp:
2955         (JSC::SLOW_PATH_DECL):
2956         * runtime/InternalFunction.cpp:
2957         (JSC::InternalFunction::createSubclassStructureSlow):
2958         * runtime/IteratorOperations.cpp:
2959         (JSC::createIteratorResultObjectStructure):
2960         * runtime/JSBoundFunction.cpp:
2961         (JSC::getBoundFunctionStructure):
2962         * runtime/JSGlobalObject.cpp:
2963         (JSC::JSGlobalObject::init):
2964         * runtime/ObjectConstructor.h:
2965         (JSC::constructEmptyObject):
2966         * runtime/PrototypeKey.h:
2967         (JSC::PrototypeKey::PrototypeKey):
2968         (JSC::PrototypeKey::executable const):
2969         (JSC::PrototypeKey::operator== const):
2970         (JSC::PrototypeKey::hash const):
2971         * runtime/PrototypeMap.cpp: Removed.
2972         * runtime/PrototypeMap.h: Removed.
2973         * runtime/StructureCache.cpp: Copied from Source/JavaScriptCore/runtime/PrototypeMap.cpp.
2974         (JSC::StructureCache::createEmptyStructure):
2975         (JSC::StructureCache::emptyStructureForPrototypeFromBaseStructure):
2976         (JSC::StructureCache::emptyObjectStructureForPrototype):
2977         (JSC::PrototypeMap::createEmptyStructure): Deleted.
2978         (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure): Deleted.
2979         (JSC::PrototypeMap::emptyObjectStructureForPrototype): Deleted.
2980         * runtime/StructureCache.h: Copied from Source/JavaScriptCore/runtime/PrototypeMap.h.
2981         (JSC::StructureCache::StructureCache):
2982         (JSC::PrototypeMap::PrototypeMap): Deleted.
2983         * runtime/VM.cpp:
2984         (JSC::VM::VM):
2985         * runtime/VM.h:
2986
2987 2017-10-09  Yusuke Suzuki  <utatane.tea@gmail.com>
2988
2989         `async` should be able to be used as an imported binding name
2990         https://bugs.webkit.org/show_bug.cgi?id=176573
2991
2992         Reviewed by Saam Barati.
2993
2994         Previously, we have ASYNC keyword in the parser. This is introduced only for performance,
2995         and ECMA262 spec does not categorize "async" to keyword. This makes parser code complicated,
2996         since ASYNC should be handled as IDENT. If we missed this ASYNC keyword, we cause a bug.
2997         For example, import declaration failed to bind imported binding to the name "async" because
2998         the parser considered ASYNC as keyword.
2999
3000         This patch removes ASYNC keyword from the parser. By carefully handling ASYNC, we can keep
3001         the current performance without using this ASYNC keyword.
3002
3003         We also add `escaped` field to token data since contextual keyword is valid only if it does
3004         not contain any escape sequences. We fix bunch of contextual keyword use with this fix too
3005         e.g. `of in for-of`. This improves test262 score.
3006
3007         * parser/Keywords.table:
3008         * parser/Lexer.cpp:
3009         (JSC::Lexer<LChar>::parseIdentifier):
3010         (JSC::Lexer<UChar>::parseIdentifier):
3011         (JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
3012         * parser/Parser.cpp:
3013         (JSC::Parser<LexerType>::parseStatementListItem):
3014         (JSC::Parser<LexerType>::parseForStatement):
3015         (JSC::Parser<LexerType>::parseStatement):
3016         (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
3017         (JSC::Parser<LexerType>::parseClass):
3018         (JSC::Parser<LexerType>::parseExportDeclaration):
3019         (JSC::Parser<LexerType>::parseAssignmentExpression):
3020         (JSC::Parser<LexerType>::parseProperty):
3021         (JSC::Parser<LexerType>::parsePrimaryExpression):
3022         (JSC::Parser<LexerType>::parseMemberExpression):
3023         (JSC::Parser<LexerType>::printUnexpectedTokenText):
3024         * parser/Parser.h:
3025         (JSC::Parser::matchContextualKeyword):
3026         * parser/ParserTokens.h:
3027         * runtime/CommonIdentifiers.h:
3028
3029 2017-10-09  Saam Barati  <sbarati@apple.com>
3030
3031         We don't need to clearEmptyObjectStructureForPrototype because JSGlobalObject* is part of the cache's key
3032         https://bugs.webkit.org/show_bug.cgi?id=177987
3033
3034         Reviewed by Filip Pizlo.
3035
3036         * runtime/JSProxy.cpp:
3037         (JSC::JSProxy::setTarget):
3038         * runtime/PrototypeMap.cpp:
3039         (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype): Deleted.
3040         * runtime/PrototypeMap.h:
3041
3042 2017-10-09  Filip Pizlo  <fpizlo@apple.com>
3043
3044         JSCell::didBecomePrototype is racy
3045         https://bugs.webkit.org/show_bug.cgi?id=178110
3046
3047         Reviewed by Saam Barati.
3048         
3049         The indexing type can be modified by any thread using CAS. So, we need to use atomics when
3050         modifying it. We don't need to use atomics when reading it though (since it's just one field).
3051
3052         * runtime/JSCellInlines.h:
3053         (JSC::JSCell::didBecomePrototype):
3054
3055 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
3056
3057         Enable gigacage on iOS
3058         https://bugs.webkit.org/show_bug.cgi?id=177586
3059
3060         Reviewed by JF Bastien.
3061
3062         The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
3063         executing JS, so the LLInt needs to know how to load from global variables on all platforms that
3064         have Gigacage. So, this teaches ARM64 how to load from global variables.
3065         
3066         Also, this makes the code handle disabling the gigacage a bit better.
3067
3068         * ftl/FTLLowerDFGToB3.cpp:
3069         (JSC::FTL::DFG::LowerDFGToB3::caged):
3070         * jit/AssemblyHelpers.h:
3071         (JSC::AssemblyHelpers::cage):
3072         (JSC::AssemblyHelpers::cageConditionally):
3073         * offlineasm/arm64.rb:
3074         * offlineasm/asm.rb:
3075         * offlineasm/instructions.rb:
3076
3077 2017-10-09  Robin Morisset  <rmorisset@apple.com>
3078
3079         Evaluate the benefit of skipping dead code in the DFGByteCodeParser when a function returns in its first block
3080         https://bugs.webkit.org/show_bug.cgi?id=177925
3081
3082         Reviewed by Saam Barati.
3083
3084         We used to do a rather weird "optimisation" in the bytecode parser: when a function would return in its first block,
3085         the rest of the function was skipped. Since it has no actual impact on any benchmarks from what I could see, I removed
3086         that code. It allows some changes to parseBlock(), since it now returns void and no-longer bool (it was returning a boolean that said whether that case happened or not).
3087
3088         * dfg/DFGByteCodeParser.cpp:
3089         (JSC::DFG::ByteCodeParser::parseBlock):
3090         (JSC::DFG::ByteCodeParser::parseCodeBlock):
3091
3092 2017-10-09  Robin Morisset  <rmorisset@apple.com>
3093
3094         Refactor the inliner to simplify block linking
3095         https://bugs.webkit.org/show_bug.cgi?id=177922
3096
3097         Reviewed by Saam Barati.
3098
3099         The biggest refactor changes the way blocks are linked. In DFGByteCodeParser, most terminals (such as Jump or Branch) jump to nullptr initially, and have
3100         some metadata indicating the bytecode index corresponding to their targets. They are later linked to the right basic block using two fields of InlineStackEntry:
3101         - m_unlinkedBlocks is just a worklist of blocks with a terminal that needs to be linked
3102         - m_linkingTargets is a dictionary from bytecode indices to BasicBlock*
3103         Before refactoring, every block was automatically added to both of these fields, for the InlineStackEntry of whatever function allocated it.
3104         This created a significant number of corner cases, such as blocks allocated in a caller, with a terminal written by an inlined callee and pointing to a block in the callee,
3105         or blocks allocated in an inline callee, with a terminal written by the caller after it returns and pointing to a block in the caller, or blocks with a manually linked
3106         terminal that needs to be taken off m_unlinkedBlocks.
3107         I changed things so that blocks are only added to m_unlinkedBlocks when their terminal gets written (see the LAST_OPCODE macro) making it a lot easier to be in the "right" InlineStackEntry,
3108         that is the one that holds their target in its m_linkingTargets field.
3109
3110         There are a few much smaller refactors in this patch:
3111         - parse() is now of type void insted of bool (it was always returning true)
3112         - The 7 and 8 arguments of handleCall were inlined in its 3 arguments version for readability
3113         - The 9 argument version was cleaned up and simplified
3114         - I made separate allocateBlock routines because the little dance with adoptRef(* new BasicBlock(...)) was being repeated in lots of places, and typos in that were a major source of bugs during other refactorings
3115         - Jumps are now created with explicit addJumpTo() functions, providing some sanity checking through asserts and didLink()
3116         - Blocks are only added to m_unlinkedBlocks if they end in a terminal that linkBlock works with (see LAST_OPCODE)
3117
3118         * dfg/DFGByteCodeParser.cpp:
3119         (JSC::DFG::ByteCodeParser::addToGraph):
3120         (JSC::DFG::ByteCodeParser::handleCall):
3121         (JSC::DFG::ByteCodeParser::refineStatically):
3122         (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
3123         (JSC::DFG::ByteCodeParser::handleVarargsCall):
3124         (JSC::DFG::ByteCodeParser::inlineCall):
3125         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
3126         (JSC::DFG::ByteCodeParser::handleInlining):
3127         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
3128         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
3129         (JSC::DFG::ByteCodeParser::parseBlock):
3130         (JSC::DFG::ByteCodeParser::parseCodeBlock):
3131         (JSC::DFG::ByteCodeParser::parse):
3132         (JSC::DFG::parse):
3133         (JSC::DFG::ByteCodeParser::cancelLinkingForBlock): Deleted.
3134         * dfg/DFGByteCodeParser.h:
3135         * dfg/DFGPlan.cpp:
3136         (JSC::DFG::Plan::compileInThreadImpl):
3137
3138 2017-10-09  Michael Saboff  <msaboff@apple.com>
3139
3140         Implement RegExp Unicode property escapes
3141         https://bugs.webkit.org/show_bug.cgi?id=172069
3142
3143         Reviewed by JF Bastien.
3144
3145         Added Unicode Properties by extending the existing CharacterClass processing.
3146
3147         Introduced a new Python script, generateYarrUnicodePropertyTables.py, that parses
3148         Unicode Database files to create character class data.  The result is a set of functions
3149         that return character classes, one for each of the required Unicode properties.
3150         There are many cases where many properties are handled by one function, primarily due to
3151         property aliases, but also due to Script_Extension properties that are the same as the
3152         Script property for the same script value.
3153
3154         Extended the BuiltInCharacterClassID enum so it can be used also for Unicode property
3155         character classes.  Unicode properties are the enum value BaseUnicodePropertyID plus a
3156         zero based value, that value being the index to the corrensponding character class
3157         function.  The generation script also creates static hashing tables similar to what we
3158         use for the generated .lut.h lookup table files.  These hashing tables map property
3159         names to the function index.  Using these hashing tables, we can lookup a property
3160         name and if present convert it to a function index.  We add that index to
3161         BaseUnicodePropertyID to create a BuiltInCharacterClassID.
3162
3163         When we do syntax parsing, we convert the property to its corresponding BuiltInCharacterClassID.
3164         When doing real parsing we takes the returned BuiltInCharacterClassID and use it to get
3165         the actual character class by calling the corresponding generated function.
3166
3167         Added a new CharacterClass constructor that can take literal arrays for ranges and matches
3168         to make the creation of large static character classes more efficent.
3169
3170         Since the Unicode character classes typically have more matches and ranges, the character
3171         class matching in the interpreter has been updated to use binary searching for matches and
3172         ranges with more than 6 entries.
3173
3174         * CMakeLists.txt:
3175         * DerivedSources.make:
3176         * JavaScriptCore.xcodeproj/project.pbxproj:
3177         * Scripts/generateYarrUnicodePropertyTables.py: Added.
3178         (openOrExit):
3179         (openUCDFileOrExit):
3180         (verifyUCDFilesExist):
3181         (ceilingToPowerOf2):
3182         (Aliases):
3183         (Aliases.__init__):
3184         (Aliases.parsePropertyAliasesFile):
3185         (Aliases.parsePropertyValueAliasesFile):
3186         (Aliases.globalAliasesFor):
3187         (Aliases.generalCategoryAliasesFor):
3188         (Aliases.generalCategoryForAlias):
3189         (Aliases.scriptAliasesFor):
3190         (Aliases.scriptNameForAlias):
3191         (PropertyData):
3192         (PropertyData.__init__):
3193         (PropertyData.setAliases):
3194         (PropertyData.makeCopy):
3195         (PropertyData.getIndex):
3196         (PropertyData.getCreateFuncName):
3197         (PropertyData.addMatch):
3198         (PropertyData.addRange):
3199         (PropertyData.addMatchUnorderedForMatchesAndRanges):
3200         (PropertyData.addRangeUnorderedForMatchesAndRanges):
3201         (PropertyData.addMatchUnordered):
3202         (PropertyData.addRangeUnordered):
3203         (PropertyData.removeMatchFromRanges):
3204         (PropertyData.removeMatch):
3205         (PropertyData.dumpMatchData):
3206         (PropertyData.dump):
3207         (PropertyData.dumpAll):
3208         (PropertyData.dumpAll.std):
3209         (PropertyData.createAndDumpHashTable):
3210         (Scripts):
3211         (Scripts.__init__):
3212         (Scripts.parseScriptsFile):
3213         (Scripts.parseScriptExtensionsFile):
3214         (Scripts.dump):
3215         (GeneralCategory):
3216         (GeneralCategory.__init__):
3217         (GeneralCategory.createSpecialPropertyData):
3218         (GeneralCategory.findPropertyGroupFor):
3219         (GeneralCategory.addNextCodePoints):
3220         (GeneralCategory.parse):
3221         (GeneralCategory.dump):
3222         (BinaryProperty):
3223         (BinaryProperty.__init__):
3224         (BinaryProperty.parsePropertyFile):
3225         (BinaryProperty.dump):
3226         * Scripts/hasher.py: Added.
3227         (stringHash):
3228         * Sources.txt:
3229         * ucd/DerivedBinaryProperties.txt: Added.
3230         * ucd/DerivedCoreProperties.txt: Added.
3231         * ucd/DerivedNormalizationProps.txt: Added.
3232         * ucd/PropList.txt: Added.
3233         * ucd/PropertyAliases.txt: Added.
3234         * ucd/PropertyValueAliases.txt: Added.
3235         * ucd/ScriptExtensions.txt: Added.
3236         * ucd/Scripts.txt: Added.
3237         * ucd/UnicodeData.txt: Added.
3238         * ucd/emoji-data.txt: Added.
3239         * yarr/Yarr.h:
3240         * yarr/YarrInterpreter.cpp:
3241         (JSC::Yarr::Interpreter::testCharacterClass):
3242         * yarr/YarrParser.h:
3243         (JSC::Yarr::Parser::parseEscape):
3244         (JSC::Yarr::Parser::parseTokens):
3245         (JSC::Yarr::Parser::isUnicodePropertyValueExpressionChar):
3246         (JSC::Yarr::Parser::tryConsumeUnicodePropertyExpression):
3247         * yarr/YarrPattern.cpp:
3248         (JSC::Yarr::CharacterClassConstructor::appendInverted):
3249         (JSC::Yarr::YarrPatternConstructor::atomBuiltInCharacterClass):
3250         (JSC::Yarr::YarrPatternConstructor::atomCharacterClassBuiltIn):
3251         (JSC::Yarr::YarrPattern::errorMessage):
3252         (JSC::Yarr::PatternTerm::dump):
3253         * yarr/YarrPattern.h:
3254         (JSC::Yarr::CharacterRange::CharacterRange):
3255         (JSC::Yarr::CharacterClass::CharacterClass):
3256         (JSC::Yarr::YarrPattern::reset):
3257         (JSC::Yarr::YarrPattern::unicodeCharacterClassFor):
3258         * yarr/YarrUnicodeProperties.cpp: Added.
3259         (JSC::Yarr::HashTable::entry const):
3260         (JSC::Yarr::unicodeMatchPropertyValue):
3261         (JSC::Yarr::unicodeMatchProperty):
3262         (JSC::Yarr::createUnicodeCharacterClassFor):
3263         * yarr/YarrUnicodeProperties.h: Added.
3264
3265 2017-10-09  Commit Queue  <commit-queue@webkit.org>
3266
3267         Unreviewed, rolling out r223015 and r223025.
3268         https://bugs.webkit.org/show_bug.cgi?id=178093
3269
3270         Regressed Kraken on iOS by 20% (Requested by keith_mi_ on
3271         #webkit).
3272
3273         Reverted changesets:
3274
3275         "Enable gigacage on iOS"
3276         https://bugs.webkit.org/show_bug.cgi?id=177586
3277         http://trac.webkit.org/changeset/223015
3278
3279         "Unreviewed, disable Gigacage on ARM64 Linux"
3280         https://bugs.webkit.org/show_bug.cgi?id=177586
3281         http://trac.webkit.org/changeset/223025
3282
3283 2017-10-09  Keith Miller  <keith_miller@apple.com>
3284
3285         Unreviewed, sort unified sources again now that they are numbered numerically rather than lexicographically.
3286
3287         * JavaScriptCore.xcodeproj/project.pbxproj:
3288
3289 2017-10-09  Ryan Haddad  <ryanhaddad@apple.com>
3290
3291         Unreviewed, rolling out r223022.
3292
3293         This change introduced 18 test262 failures.
3294
3295         Reverted changeset:
3296
3297         "`async` should be able to be used as an imported binding
3298         name"
3299         https://bugs.webkit.org/show_bug.cgi?id=176573
3300         http://trac.webkit.org/changeset/223022
3301
3302 2017-10-09  Robin Morisset  <rmorisset@apple.com>
3303
3304         Make the names of the options consistent
3305         https://bugs.webkit.org/show_bug.cgi?id=177933
3306
3307         Reviewed by Saam Barati.
3308
3309         I added an alias so the old spelling still works.
3310         I also fixed a bunch of typos in comments all around the codebase.
3311
3312         * b3/B3LowerToAir.cpp:
3313         * dfg/DFGByteCodeParser.cpp:
3314         (JSC::DFG::ByteCodeParser::parseBlock):
3315         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
3316         * dfg/DFGOperations.h:
3317         * dfg/DFGSSAConversionPhase.h:
3318         * dfg/DFGSpeculativeJIT.h:
3319         * ftl/FTLLowerDFGToB3.cpp:
3320         (JSC::FTL::DFG::LowerDFGToB3::lower):
3321         * ftl/FTLOSREntry.cpp:
3322         (JSC::FTL::prepareOSREntry):
3323         * jit/CallFrameShuffler.cpp:
3324         (JSC::CallFrameShuffler::prepareForTailCall):
3325         * parser/Nodes.h:
3326         * parser/Parser.cpp:
3327         (JSC::Parser<LexerType>::parseExportDeclaration):
3328         * runtime/Options.h: