5f62f557d720f1af3e60383e4532eda584420e0f
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-07-10  Yusuke Suzuki  <utatane.tea@gmail.com>
2
3         [ES6] Promise.{all,race} no longer use @@species
4         https://bugs.webkit.org/show_bug.cgi?id=159615
5
6         Reviewed by Keith Miller.
7
8         As per the latest ES draft, Promise.{all,race} no longer use @@species.
9         So, this patch drops FIXMEs.
10
11         * builtins/PromiseConstructor.js:
12         (all):
13         (race):
14         * tests/stress/ignore-promise-species.js: Added.
15         (shouldBe):
16         (DerivedPromise.prototype.get Symbol):
17         (DerivedPromise):
18
19 2016-07-10  Commit Queue  <commit-queue@webkit.org>
20
21         Unreviewed, rolling out r203037.
22         https://bugs.webkit.org/show_bug.cgi?id=159614
23
24         The JSC tests are breaking in elcapitan-debug-tests-jsc and
25         elcapitan-release-tests-jsc (Requested by caiolima on
26         #webkit).
27
28         Reverted changeset:
29
30         "ECMAScript 2016: %TypedArray%.prototype.includes
31         implementation"
32         https://bugs.webkit.org/show_bug.cgi?id=159385
33         http://trac.webkit.org/changeset/203037
34
35 2016-07-10  Caio Lima  <ticaiolima@gmail.com>
36
37         ECMAScript 2016: %TypedArray%.prototype.includes implementation
38         https://bugs.webkit.org/show_bug.cgi?id=159385
39
40         Reviewed by Benjamin Poulain.
41
42         This patch implements the ECMAScript 2016:
43         %TypedArray%.prototype.includes
44         following spec 22.2.3.14
45         https://tc39.github.io/ecma262/2016/#sec-%typedarray%.prototype.includes
46
47         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
48         (JSC::genericTypedArrayViewProtoFuncIncludes):
49         * runtime/JSTypedArrayViewPrototype.cpp:
50         (JSC::typedArrayViewProtoFuncIncludes):
51         (JSC::JSTypedArrayViewPrototype::finishCreation):
52
53 2016-07-09  Filip Pizlo  <fpizlo@apple.com>
54
55         REGRESSION(201900): validation failure for GetByOffset/PutByOffset in VALIDATE((node), node->child1().node() == node->child2().node() || node->child1()->result() == NodeResultStorage)
56         https://bugs.webkit.org/show_bug.cgi?id=159603
57
58         Reviewed by Keith Miller.
59         
60         This removes an incorrect validation rule and replaces it with a FIXME about how to make this
61         aspect of IR easier to validate soundly.
62         
63         It's not valid to assert that two children of a node are the same. It should always be valid
64         to take:
65         
66         Foo(@x, @x)
67         
68         and turn it into:
69         
70         a: ValueRep(@x)
71         b: ValueRep(@x)
72         Foo(@a, @b)
73         
74         or even something like:
75         
76         y: Identity(@y)
77         Foo(@x, @y)
78         
79         That's because it should be possible to rewire any data flow edge something that produces an
80         equivalent value.
81         
82         The validation rule that this patch removes meant that such rewirings were invalid on
83         GetByOffset/PutByOffset. FixupPhase did such a rewiring sometimes.
84
85         * dfg/DFGValidate.cpp:
86         * tests/stress/get-by-offset-double.js: Added.
87
88 2016-07-09  Keith Miller  <keith_miller@apple.com>
89
90         appendMemcpy might fail in concatAppendOne
91         https://bugs.webkit.org/show_bug.cgi?id=159601
92         <rdar://problem/27211300>
93
94         Reviewed by Mark Lam.
95
96         There are multiple reasons why we might fail appendMemcpy. One
97         reason, which I suspect was the source of the crashes, is that one
98         of the Array prototypes has an indexed property. This patch
99         consolidates the two old cases by just creating an array then
100         attempting to memcpy append. If that fails, we fall back to
101         moveElements.
102
103         * runtime/ArrayPrototype.cpp:
104         (JSC::concatAppendOne):
105         * tests/stress/concat-with-holesMustForwardToPrototype.js: Added.
106         (arrayEq):
107
108 2016-07-09  Benjamin Poulain  <bpoulain@apple.com>
109
110         [JSC] Fix the Template Raw Value of \ (escape) + LineTerminatorSequence
111         https://bugs.webkit.org/show_bug.cgi?id=159595
112
113         Reviewed by Yusuke Suzuki.
114
115         The spec (https://tc39.github.io/ecma262/#sec-static-semantics-tv-and-trv)
116         says:
117         "The TRV of LineContinuation::\LineTerminatorSequence is the sequence
118          consisting of the code unit value 0x005C followed by the code units
119          of TRV of LineTerminatorSequence."
120         
121         We were not normalizing the LineTerminatorSequence in that case, but it should
122         be as it is the TRV of LineTerminatorSequence.
123
124         * parser/Lexer.cpp:
125         (JSC::Lexer<T>::parseTemplateLiteral):
126         * tests/stress/tagged-templates-raw-strings.js:
127
128 2016-07-08  Saam Barati  <sbarati@apple.com>
129
130         We may add a ReadOnly property without setting the corresponding bit on Structure
131         https://bugs.webkit.org/show_bug.cgi?id=159542
132         <rdar://problem/27084591>
133
134         Reviewed by Benjamin Poulain.
135
136         The reason this usually is OK is due to happenstance. Often, instances that putDirectWithoutTransition
137         also happen to have a static property table. Having a static property table causes the
138         HasReadOnlyOrGetterSetterPropertiesExcludingProto on the structure to be set. However, 
139         there are times where an object calls putDirectWithoutTransition, and it doesn't have a
140         static property hash table. The fix is simple, putDirectWithTransition needs to set the
141         HasReadOnlyOrGetterSetterPropertiesExcludingProto if it puts a ReadOnly property.
142
143         * runtime/JSObject.h:
144         (JSC::JSObject::putDirectWithoutTransition):
145         * tests/stress/proper-property-store-with-prototype-property-that-is-not-writable.js: Added.
146         (assert):
147
148 2016-07-08  Michael Saboff  <msaboff@apple.com>
149
150         ASSERTION FAILED: Heap::isMarked(cell) in SlotVisitor::appendToMarkStack(JSC::JSCell *)
151         https://bugs.webkit.org/show_bug.cgi?id=159588
152
153         Reviewed by Geoffrey Garen.
154
155         We were jettisoning a CodeBlock during GC that won't survive and its owning script
156         won't survive either.  We can't install any code on the owning script as that involves
157         a write barrier that will "pull" the script back into the remembered set.  Badness would
158         ensue.  Added an early return in CodeBlock::jettison() when we are garbage collecting
159         and the owning script isn't marked.
160
161         * bytecode/CodeBlock.cpp:
162         (JSC::CodeBlock::jettison):
163
164 2016-07-08  Mark Lam  <mark.lam@apple.com>
165
166         Move CallFrame header info from JSStack.h to CallFrame.h
167         https://bugs.webkit.org/show_bug.cgi?id=159549
168
169         Reviewed by Geoffrey Garen.
170
171         CallFrame.h is a much better location for CallFrame header info.
172
173         Replaced CallFrame::init() with ExecState::initGlobalExec() because normal
174         CallFrames are setup by a different mechanism now.  Only the globalExec is still
175         using it.  So, might as well change it to be specifically for the globalExec.
176
177         Removed the use of JSStack::containsAddress() in ExecState::initGlobalExec()
178         because it is not relevant to the globalExec.
179
180         Also removed some unused code: JSStack::gatherConservativeRoots() and
181         JSStack::sanitizeStack() is never called for JIT builds.
182
183         * bytecode/PolymorphicAccess.cpp:
184         (JSC::AccessCase::generateImpl):
185         * bytecode/VirtualRegister.h:
186         (JSC::VirtualRegister::isValid):
187         (JSC::VirtualRegister::isLocal):
188         (JSC::VirtualRegister::isArgument):
189         (JSC::VirtualRegister::isHeader):
190         (JSC::VirtualRegister::isConstant):
191         (JSC::VirtualRegister::toLocal):
192         (JSC::VirtualRegister::toArgument):
193         * bytecompiler/BytecodeGenerator.cpp:
194         (JSC::BytecodeGenerator::BytecodeGenerator):
195         (JSC::BytecodeGenerator::emitCall):
196         (JSC::BytecodeGenerator::emitConstruct):
197         * bytecompiler/BytecodeGenerator.h:
198         (JSC::CallArguments::thisRegister):
199         (JSC::CallArguments::argumentRegister):
200         (JSC::CallArguments::stackOffset):
201         (JSC::CallArguments::argumentCountIncludingThis):
202         (JSC::CallArguments::argumentsNode):
203         (JSC::BytecodeGenerator::registerFor):
204         * bytecompiler/NodesCodegen.cpp:
205         (JSC::emitHomeObjectForCallee):
206         (JSC::emitGetSuperFunctionForConstruct):
207         (JSC::CallArguments::CallArguments):
208         * dfg/DFGArgumentsEliminationPhase.cpp:
209         * dfg/DFGArgumentsUtilities.cpp:
210         (JSC::DFG::argumentsInvolveStackSlot):
211         (JSC::DFG::emitCodeToGetArgumentsArrayLength):
212         * dfg/DFGByteCodeParser.cpp:
213         (JSC::DFG::ByteCodeParser::get):
214         (JSC::DFG::ByteCodeParser::findArgumentPositionForLocal):
215         (JSC::DFG::ByteCodeParser::flush):
216         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
217         (JSC::DFG::ByteCodeParser::getArgumentCount):
218         (JSC::DFG::ByteCodeParser::inlineCall):
219         (JSC::DFG::ByteCodeParser::handleInlining):
220         (JSC::DFG::ByteCodeParser::handleGetById):
221         (JSC::DFG::ByteCodeParser::handlePutById):
222         (JSC::DFG::ByteCodeParser::parseBlock):
223         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
224         * dfg/DFGClobberize.h:
225         (JSC::DFG::clobberize):
226         * dfg/DFGGraph.cpp:
227         (JSC::DFG::Graph::isLiveInBytecode):
228         * dfg/DFGGraph.h:
229         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
230         * dfg/DFGJITCompiler.cpp:
231         (JSC::DFG::JITCompiler::compileEntry):
232         (JSC::DFG::JITCompiler::compileSetupRegistersForEntry):
233         (JSC::DFG::JITCompiler::compileFunction):
234         * dfg/DFGJITCompiler.h:
235         (JSC::DFG::JITCompiler::emitStoreCallSiteIndex):
236         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
237         (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
238         * dfg/DFGOSREntry.cpp:
239         (JSC::DFG::prepareOSREntry):
240         * dfg/DFGOSRExitCompiler.cpp:
241         (JSC::DFG::OSRExitCompiler::emitRestoreArguments):
242         * dfg/DFGOSRExitCompilerCommon.cpp:
243         (JSC::DFG::reifyInlinedCallFrames):
244         * dfg/DFGOSRExitCompilerCommon.h:
245         (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
246         * dfg/DFGPreciseLocalClobberize.h:
247         (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
248         * dfg/DFGSpeculativeJIT.cpp:
249         (JSC::DFG::SpeculativeJIT::emitGetLength):
250         (JSC::DFG::SpeculativeJIT::emitGetCallee):
251         (JSC::DFG::SpeculativeJIT::emitGetArgumentStart):
252         (JSC::DFG::SpeculativeJIT::compileCreateDirectArguments):
253         * dfg/DFGSpeculativeJIT32_64.cpp:
254         (JSC::DFG::SpeculativeJIT::emitCall):
255         (JSC::DFG::SpeculativeJIT::compile):
256         * dfg/DFGSpeculativeJIT64.cpp:
257         (JSC::DFG::SpeculativeJIT::emitCall):
258         (JSC::DFG::SpeculativeJIT::compile):
259         * dfg/DFGStackLayoutPhase.cpp:
260         (JSC::DFG::StackLayoutPhase::run):
261         * dfg/DFGThunks.cpp:
262         (JSC::DFG::osrEntryThunkGenerator):
263         * ftl/FTLLink.cpp:
264         (JSC::FTL::link):
265         * ftl/FTLLowerDFGToB3.cpp:
266         (JSC::FTL::DFG::LowerDFGToB3::lower):
267         (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
268         (JSC::FTL::DFG::LowerDFGToB3::compileGetCallee):
269         (JSC::FTL::DFG::LowerDFGToB3::compileGetArgumentCountIncludingThis):
270         (JSC::FTL::DFG::LowerDFGToB3::compileGetScope):
271         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
272         (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
273         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
274         (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenPrologue):
275         (JSC::FTL::DFG::LowerDFGToB3::getArgumentsLength):
276         (JSC::FTL::DFG::LowerDFGToB3::getCurrentCallee):
277         (JSC::FTL::DFG::LowerDFGToB3::getArgumentsStart):
278         (JSC::FTL::DFG::LowerDFGToB3::callPreflight):
279         * ftl/FTLOSRExitCompiler.cpp:
280         (JSC::FTL::compileStub):
281         * ftl/FTLSlowPathCall.h:
282         (JSC::FTL::callOperation):
283         * interpreter/CallFrame.cpp:
284         (JSC::ExecState::initGlobalExec):
285         (JSC::CallFrame::callSiteBitsAreBytecodeOffset):
286         (JSC::CallFrame::callSiteAsRawBits):
287         (JSC::CallFrame::unsafeCallSiteAsRawBits):
288         (JSC::CallFrame::callSiteIndex):
289         (JSC::CallFrame::setCurrentVPC):
290         (JSC::CallFrame::callSiteBitsAsBytecodeOffset):
291         * interpreter/CallFrame.h:
292         (JSC::CallSiteIndex::CallSiteIndex):
293         (JSC::ExecState::calleeAsValue):
294         (JSC::ExecState::callee):
295         (JSC::ExecState::unsafeCallee):
296         (JSC::ExecState::codeBlock):
297         (JSC::ExecState::unsafeCodeBlock):
298         (JSC::ExecState::scope):
299         (JSC::ExecState::setCallerFrame):
300         (JSC::ExecState::setScope):
301         (JSC::ExecState::argumentCount):
302         (JSC::ExecState::argumentCountIncludingThis):
303         (JSC::ExecState::argumentOffset):
304         (JSC::ExecState::argumentOffsetIncludingThis):
305         (JSC::ExecState::offsetFor):
306         (JSC::ExecState::noCaller):
307         (JSC::ExecState::setArgumentCountIncludingThis):
308         (JSC::ExecState::setCallee):
309         (JSC::ExecState::setCodeBlock):
310         (JSC::ExecState::setReturnPC):
311         (JSC::ExecState::argIndexForRegister):
312         (JSC::ExecState::callerFrameAndPC):
313         (JSC::ExecState::unsafeCallerFrameAndPC):
314         (JSC::ExecState::init): Deleted.
315         * interpreter/Interpreter.cpp:
316         (JSC::Interpreter::dumpRegisters):
317         * interpreter/Interpreter.h:
318         (JSC::calleeFrameForVarargs):
319         * interpreter/JSStack.h:
320         (JSC::JSStack::containsAddress):
321         (JSC::JSStack::gatherConservativeRoots): Deleted.
322         (JSC::JSStack::sanitizeStack): Deleted.
323         * jit/AssemblyHelpers.cpp:
324         (JSC::AssemblyHelpers::jitAssertArgumentCountSane):
325         (JSC::AssemblyHelpers::emitRandomThunk):
326         * jit/AssemblyHelpers.h:
327         (JSC::AssemblyHelpers::restoreReturnAddressBeforeReturn):
328         (JSC::AssemblyHelpers::emitGetFromCallFrameHeaderPtr):
329         (JSC::AssemblyHelpers::emitGetFromCallFrameHeader32):
330         (JSC::AssemblyHelpers::emitGetFromCallFrameHeader64):
331         (JSC::AssemblyHelpers::emitPutToCallFrameHeader):
332         (JSC::AssemblyHelpers::emitPutToCallFrameHeaderBeforePrologue):
333         (JSC::AssemblyHelpers::emitPutPayloadToCallFrameHeaderBeforePrologue):
334         (JSC::AssemblyHelpers::emitPutTagToCallFrameHeaderBeforePrologue):
335         (JSC::AssemblyHelpers::calleeFrameSlot):
336         * jit/CCallHelpers.cpp:
337         (JSC::CCallHelpers::logShadowChickenProloguePacket):
338         * jit/CCallHelpers.h:
339         (JSC::CCallHelpers::prepareForTailCallSlow):
340         * jit/CallFrameShuffler.cpp:
341         (JSC::CallFrameShuffler::CallFrameShuffler):
342         (JSC::CallFrameShuffler::dump):
343         (JSC::CallFrameShuffler::extendFrameIfNeeded):
344         (JSC::CallFrameShuffler::prepareForSlowPath):
345         (JSC::CallFrameShuffler::prepareForTailCall):
346         (JSC::CallFrameShuffler::prepareAny):
347         * jit/CallFrameShuffler.h:
348         (JSC::CallFrameShuffler::snapshot):
349         (JSC::CallFrameShuffler::setCalleeJSValueRegs):
350         (JSC::CallFrameShuffler::assumeCalleeIsCell):
351         (JSC::CallFrameShuffler::numLocals):
352         (JSC::CallFrameShuffler::getOld):
353         (JSC::CallFrameShuffler::setOld):
354         (JSC::CallFrameShuffler::firstOld):
355         (JSC::CallFrameShuffler::lastOld):
356         (JSC::CallFrameShuffler::isValidOld):
357         (JSC::CallFrameShuffler::argCount):
358         (JSC::CallFrameShuffler::getNew):
359         * jit/JIT.cpp:
360         (JSC::JIT::compileWithoutLinking):
361         * jit/JIT.h:
362         * jit/JITCall.cpp:
363         (JSC::JIT::compileSetupVarargsFrame):
364         (JSC::JIT::compileCallEvalSlowCase):
365         (JSC::JIT::compileOpCall):
366         * jit/JITCall32_64.cpp:
367         (JSC::JIT::compileSetupVarargsFrame):
368         (JSC::JIT::compileCallEvalSlowCase):
369         (JSC::JIT::compileOpCall):
370         * jit/JITInlines.h:
371         (JSC::JIT::getConstantOperand):
372         (JSC::JIT::emitPutIntToCallFrameHeader):
373         (JSC::JIT::updateTopCallFrame):
374         * jit/JITOpcodes.cpp:
375         (JSC::JIT::emit_op_get_scope):
376         (JSC::JIT::emit_op_argument_count):
377         (JSC::JIT::emit_op_get_rest_length):
378         * jit/JITOpcodes32_64.cpp:
379         (JSC::JIT::privateCompileCTINativeCall):
380         (JSC::JIT::emit_op_get_scope):
381         * jit/JSInterfaceJIT.h:
382         (JSC::JSInterfaceJIT::emitJumpIfNotType):
383         (JSC::JSInterfaceJIT::emitGetFromCallFrameHeaderPtr):
384         (JSC::JSInterfaceJIT::emitPutToCallFrameHeader):
385         (JSC::JSInterfaceJIT::emitPutCellToCallFrameHeader):
386         * jit/SetupVarargsFrame.cpp:
387         (JSC::emitSetVarargsFrame):
388         (JSC::emitSetupVarargsFrameFastCase):
389         * jit/SpecializedThunkJIT.h:
390         (JSC::SpecializedThunkJIT::SpecializedThunkJIT):
391         * jit/ThunkGenerators.cpp:
392         (JSC::nativeForGenerator):
393         (JSC::arityFixupGenerator):
394         (JSC::boundThisNoArgsFunctionCallGenerator):
395         * llint/LLIntData.cpp:
396         (JSC::LLInt::Data::performAssertions):
397         * llint/LLIntSlowPaths.cpp:
398         (JSC::LLInt::genericCall):
399         (JSC::LLInt::varargsSetup):
400         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
401         * runtime/CommonSlowPaths.h:
402         (JSC::CommonSlowPaths::arityCheckFor):
403         * runtime/JSGlobalObject.cpp:
404         (JSC::JSGlobalObject::init):
405         * runtime/JSGlobalObject.h:
406         * runtime/StackAlignment.h:
407         (JSC::roundArgumentCountToAlignFrame):
408         (JSC::roundLocalRegisterCountForFramePointerOffset):
409         (JSC::logStackAlignmentRegisters):
410         * wasm/WASMFunctionCompiler.h:
411         (JSC::WASMFunctionCompiler::startFunction):
412         (JSC::WASMFunctionCompiler::endFunction):
413         (JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer):
414         (JSC::WASMFunctionCompiler::callAndUnboxResult):
415         * wasm/WASMFunctionSyntaxChecker.h:
416         (JSC::WASMFunctionSyntaxChecker::updateTempStackHeightForCall):
417
418 2016-07-08  Chris Dumez  <cdumez@apple.com>
419
420         Object.defineProperty() should maintain existing getter / setter if not overridden in the new descriptor
421         https://bugs.webkit.org/show_bug.cgi?id=159576
422         <rdar://problem/27242197>
423
424         Reviewed by Mark Lam.
425
426         Object.defineProperty() should maintain existing getter / setter if not
427         overridden in the new descriptor. Previously, if the property is a had
428         a custom getter / setter, and if the new descriptor only had a setter
429         (or only a getter), JSC would clear the existing getter (or setter).
430         This behavior did not match the EcmaScript specification or Firefox /
431         Chrome. This patch fixes the issue.
432
433         This fixes searching and search suggestions on www.iciba.com.
434
435         * runtime/JSObject.cpp:
436         (JSC::validateAndApplyPropertyDescriptor):
437
438 2016-07-08  Michael Saboff  <msaboff@apple.com>
439
440         Dumping the object graph doesn't work with verbose GC logging
441         https://bugs.webkit.org/show_bug.cgi?id=159569
442
443         Reviewed by Mark Lam.
444
445         The current object graph logging code tries to revisits the graph.  This doesn't work
446         correctly and asking around it isn't used.  The only way to dump the true object graph
447         is to log while we GC and that has obvious performance implications.
448         Therefore I eliminated GCLogging::dumpObjectGraph() and related code.  
449
450         * heap/GCLogging.cpp:
451         (JSC::GCLogging::levelAsString):
452         (JSC::LoggingFunctor::LoggingFunctor): Deleted.
453         (JSC::LoggingFunctor::~LoggingFunctor): Deleted.
454         (JSC::LoggingFunctor::operator()): Deleted.
455         (JSC::LoggingFunctor::log): Deleted.
456         (JSC::LoggingFunctor::reviveCells): Deleted.
457         (JSC::LoggingFunctor::returnValue): Deleted.
458         (JSC::GCLogging::dumpObjectGraph): Deleted.
459         * heap/Heap.cpp:
460         (JSC::Heap::didFinishCollection):
461
462 2016-07-08  Keith Miller  <keith_miller@apple.com>
463
464         speculateTypedArrayIsNotNeutered has an inverted speculation
465         https://bugs.webkit.org/show_bug.cgi?id=159571
466
467         Reviewed by Mark Lam.
468
469         For some confusing reason FTLLowerDFGToB3 takes the condition the
470         speculation wants to be false. This issue caused
471         typedarray-access-monomorphic-neutered.js to fail on the bots.
472
473         * ftl/FTLLowerDFGToB3.cpp:
474         (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
475
476 2016-07-08  Mark Lam  <mark.lam@apple.com>
477
478         Rename jsCPUStackLimit to osStackLimitWithReserve and jsEmulatedStackLimit to cloopStackLimit.
479         https://bugs.webkit.org/show_bug.cgi?id=159544
480
481         Reviewed by Geoffrey Garen.
482
483         This patch does the following refactoring:
484         1. Rename jsCPUStackLimit to osStackLimitWithReserve.
485         2. Rename jsEmulatedStackLimit to cloopStackLimit.
486         2. Remove llintStackLimit (which previously is either an alias for
487            jsCPUStackLimit or jsEmulatedStackLimit depending on whether we have a JIT or
488            C Loop build).  Instead, we'll change the LLINT to conditionally use the
489            osStackLimitWithReserve or cloopStackLimit.
490
491         There are no semantic changes.
492
493         * dfg/DFGJITCompiler.cpp:
494         (JSC::DFG::JITCompiler::compile):
495         (JSC::DFG::JITCompiler::compileFunction):
496         * ftl/FTLLowerDFGToB3.cpp:
497         (JSC::FTL::DFG::LowerDFGToB3::lower):
498         * interpreter/JSStack.cpp:
499         (JSC::JSStack::JSStack):
500         (JSC::JSStack::growSlowCase):
501         (JSC::JSStack::lowAddress):
502         (JSC::JSStack::highAddress):
503         * interpreter/JSStack.h:
504         * interpreter/JSStackInlines.h:
505         (JSC::JSStack::ensureCapacityFor):
506         (JSC::JSStack::shrink):
507         (JSC::JSStack::grow):
508         (JSC::JSStack::setCLoopStackLimit):
509         (JSC::JSStack::setJSEmulatedStackLimit): Deleted.
510         * jit/JIT.cpp:
511         (JSC::JIT::compileWithoutLinking):
512         * jit/SetupVarargsFrame.cpp:
513         (JSC::emitSetupVarargsFrameFastCase):
514         * llint/LLIntSlowPaths.cpp:
515         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
516         * llint/LowLevelInterpreter.asm:
517         * llint/LowLevelInterpreter32_64.asm:
518         * llint/LowLevelInterpreter64.asm:
519         * runtime/RegExp.cpp:
520         (JSC::RegExp::finishCreation):
521         (JSC::RegExp::compile):
522         (JSC::RegExp::compileMatchOnly):
523         * runtime/VM.cpp:
524         (JSC::VM::updateStackLimit):
525         * runtime/VM.h:
526         (JSC::VM::reservedZoneSize):
527         (JSC::VM::osStackLimitWithReserve):
528         (JSC::VM::addressOfOSStackLimitWithReserve):
529         (JSC::VM::cloopStackLimit):
530         (JSC::VM::setCLoopStackLimit):
531         (JSC::VM::isSafeToRecurse):
532         (JSC::VM::jsCPUStackLimit): Deleted.
533         (JSC::VM::addressOfJSCPUStackLimit): Deleted.
534         (JSC::VM::jsEmulatedStackLimit): Deleted.
535         (JSC::VM::setJSEmulatedStackLimit): Deleted.
536         * wasm/WASMFunctionCompiler.h:
537         (JSC::WASMFunctionCompiler::startFunction):
538
539 2016-07-08  Commit Queue  <commit-queue@webkit.org>
540
541         Unreviewed, rolling out r202799.
542         https://bugs.webkit.org/show_bug.cgi?id=159568
543
544         Caused build failure (Requested by perarne on #webkit).
545
546         Reverted changeset:
547
548         "[Win] DLLs are missing version information."
549         https://bugs.webkit.org/show_bug.cgi?id=159349
550         http://trac.webkit.org/changeset/202799
551
552 2016-07-08  Youenn Fablet  <youenn@apple.com>
553
554         Built-in generator should generate files with a default copyright
555         https://bugs.webkit.org/show_bug.cgi?id=159561
556
557         Reviewed by Alex Christensen.
558
559         * Scripts/builtins/builtins_model.py:
560         (BuiltinsCollection._parse_copyright_lines): Adding default copyright to the parsed copyrights.
561         * Scripts/builtins/builtins_templates.py:
562         (BuiltinsGeneratorTemplates): Adding a default copyright.
563         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result: Rebasing with added default copyright.
564         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result: Ditto.
565         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result: Ditto.
566         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result: Ditto.
567         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result: Ditto.
568         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result: Ditto.
569         * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result: Ditto.
570         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result: Ditto.
571         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result: Ditto.
572         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result: Ditto.
573         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result: Ditto.
574         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result: Ditto.
575
576
577 2016-07-08  Keith Miller  <keith_miller@apple.com>
578
579         TypedArrays need more isNeutered checks.
580         https://bugs.webkit.org/show_bug.cgi?id=159231
581
582         Reviewed by Filip Pizlo.
583
584         According to the ES6 spec if a user tries to get, set, or define a
585         property on a neutered TypedArray we should throw an
586         exception. Currently, if a user tries to get an out of bounds
587         access on a TypedArray we will always OSR.  This makes handling
588         the exception easy as all we need to do is make out of bounds gets
589         in PolymorphicAccess go to the slow path, which will then throw
590         the appropriate exception. For the case of set, we need ensure we
591         don't OSR on each out of bounds put since, for some confusing
592         reason, people do this.  Thus, for GetByVal in the DFG/FTL if the
593         user accesses out of bounds we then need to check if the view has
594         been neutered. If it is neutered then we will OSR.
595
596         Additionally, this patch adds a bunch of isNeutered checks to
597         various prototype functions for TypedArray, which are needed for
598         correctness.
599
600         * dfg/DFGSpeculativeJIT.cpp:
601         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
602         (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
603         (JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
604         * dfg/DFGSpeculativeJIT.h:
605         * ftl/FTLLowerDFGToB3.cpp:
606         (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
607         (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
608         * jit/JITPropertyAccess.cpp:
609         (JSC::JIT::emitIntTypedArrayPutByVal):
610         (JSC::JIT::emitFloatTypedArrayPutByVal):
611         * runtime/JSArrayBufferView.h:
612         * runtime/JSCJSValue.h:
613         (JSC::encodedJSUndefined):
614         (JSC::encodedJSValue):
615         * runtime/JSGenericTypedArrayView.h:
616         * runtime/JSGenericTypedArrayViewInlines.h:
617         (JSC::JSGenericTypedArrayView<Adaptor>::throwNeuteredTypedArrayTypeError):
618         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
619         (JSC::JSGenericTypedArrayView<Adaptor>::put):
620         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
621         (JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
622         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
623         (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
624         (JSC::JSGenericTypedArrayView<Adaptor>::deletePropertyByIndex):
625         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
626         (JSC::genericTypedArrayViewProtoFuncCopyWithin):
627         (JSC::genericTypedArrayViewProtoFuncFill):
628         (JSC::genericTypedArrayViewProtoFuncIndexOf):
629         (JSC::genericTypedArrayViewProtoFuncJoin):
630         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
631         (JSC::genericTypedArrayViewProtoFuncSlice):
632         (JSC::genericTypedArrayViewProtoFuncSubarray):
633         * tests/stress/fold-typed-array-properties.js:
634         * tests/stress/typedarray-access-monomorphic-neutered.js: Added.
635         (check):
636         (test):
637         (testFTL):
638         * tests/stress/typedarray-access-neutered.js: Added.
639         (check):
640         (test):
641         * tests/stress/typedarray-functions-with-neutered.js:
642         (defaultForArg):
643         (callWithArgs):
644         (checkArgumentsForType):
645         (checkArguments):
646         * tests/stress/typedarray-view-string-properties-neutered.js: Added.
647         (call):
648         (test):
649
650 2016-07-08  Youenn Fablet  <youenn@apple.com>
651
652         Generate WebCore builtin wrapper files
653         https://bugs.webkit.org/show_bug.cgi?id=159461
654
655         Reviewed by Brian Burg.
656
657         Updating builtin generator to generate wrapper files used in WebCore (See WebCore change log).
658         Rebasing builtins generator test results according generator changes by activating wrapper file generation for
659         WebCore builtins tests.
660
661         * CMakeLists.txt:
662         * DerivedSources.make:
663         * JavaScriptCore.xcodeproj/project.pbxproj:
664         * Scripts/builtins/builtins.py: Adding new generators.
665         * Scripts/builtins/builtins_generate_internals_wrapper_header.py: Added to generate WebCoreJSBuiltinInternals.h.
666         * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py: Added to generate WebCoreJSBuiltinInternals.cpp.
667         * Scripts/builtins/builtins_generate_wrapper_header.py: Added to generate WebCoreJSBuiltins.h.
668         * Scripts/builtins/builtins_generate_wrapper_implementation.py: Added to generate WebCoreJSBuiltins.cpp.
669         * Scripts/generate-js-builtins.py: Adding new option to activate generation of the wrapper files.
670         (generate_bindings_for_builtins_files):
671         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
672         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
673         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
674         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
675         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
676
677 2016-07-07  Joseph Pecoraro  <pecoraro@apple.com>
678
679         padStart/padEnd with Infinity produces unexpected result
680         https://bugs.webkit.org/show_bug.cgi?id=159543
681
682         Reviewed by Benjamin Poulain.
683
684         * builtins/GlobalOperations.js:
685         (globalPrivate.toLength):
686         Fix style.
687
688         * builtins/StringPrototype.js:
689         (padStart):
690         (padEnd):
691         After all observable operations, and after empty string has been handled,
692         throw an out of memory error if the resulting string would be greater
693         than the maximum string size.
694
695         * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors-proxy.js:
696         (shouldThrow): Deleted.
697         * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors.js:
698         (shouldThrow):
699         (testMeta):
700         * tests/es6/String.prototype_methods_String.prototype.padEnd.js:
701         (shouldThrow):
702         (TestToLength):
703         (TestMemoryLimits):
704         (TestMeta): Deleted.
705         * tests/es6/String.prototype_methods_String.prototype.padStart.js:
706         (shouldThrow):
707         (TestToLength):
708         (TestMemoryLimits):
709         Replace incorrect shouldThrow(..., errorType) with explicit shouldThrow(..., errorMessage).
710         The old shouldThrow would incorrectly succeed if the expected error type was just "Error".
711         Now we explicitly check the error message.
712
713 2016-07-07  Benjamin Poulain  <benjamin@webkit.org>
714
715         [JSC] String.prototype[Symbol.iterator] needs a name
716         https://bugs.webkit.org/show_bug.cgi?id=159541
717
718         Reviewed by Yusuke Suzuki.
719
720         A man needs a name.
721         Spec: https://tc39.github.io/ecma262/#sec-string.prototype-@@iterator
722
723         * runtime/StringPrototype.cpp:
724         (JSC::StringPrototype::finishCreation):
725
726 2016-07-07  Michael Saboff  <msaboff@apple.com>
727
728         REGRESSION(184445): Need to insert a StoreBarrier when we don't know child's epoch
729         https://bugs.webkit.org/show_bug.cgi?id=159537
730
731         Reviewed by Benjamin Poulain.
732
733         We weren't checking the case of a child node with a null epoch.  The problem surfaces
734         when the base node of a PutByVal variant has a non-null epoch, because it represents an
735         allocation in the current function, while the child of the same node has an unknown epoch.
736         Added a check that the child node is not null before comparing the epochs of the base and
737         child nodes.
738
739         The added test creates the problem circumstance by doing a full GC to place an array in
740         remembered space, allocating a new object followed by an eden GC.  The new object is
741         only referenced by the array and therefore won't be visited Without the store barrier.
742         The test may crash or more likely get the wrong answer with the bug.
743
744         * dfg/DFGStoreBarrierInsertionPhase.cpp:
745         * tests/stress/regress-159537.js: Added test.
746         (MyNumber):
747         (MyNumber.prototype.plusOne):
748         (bar):
749         (foo):
750         (test):
751
752 2016-07-07  Joseph Pecoraro  <pecoraro@apple.com>
753
754         Unexpected "Out of memory" error for "x".repeat(-1)
755         https://bugs.webkit.org/show_bug.cgi?id=159529
756
757         Reviewed by Benjamin Poulain.
758
759         * builtins/StringPrototype.js:
760         (globalPrivate.repeatSlowPath):
761         (repeat):
762         Move the @toInteger and range checking to the always path,
763         since the spec does say it should always happen. Also remove
764         the duplication of the fast path here.
765
766         * runtime/StringPrototype.cpp:
767         (JSC::repeatCharacter):
768         Remove unused function.
769
770         (JSC::stringProtoFuncRepeatCharacter):
771         ASSERT if given a negative number. This is a private function
772         only used internally.
773
774         * tests/stress/string-repeat-edge-cases.js:
775         (shouldThrow):
776         Update expected error message.
777
778 2016-07-07  Benjamin Poulain  <benjamin@webkit.org>
779
780         [JSC] Array.prototype[Symbol.unscopables] should have the "includes" property
781         https://bugs.webkit.org/show_bug.cgi?id=159504
782
783         Reviewed by Keith Miller.
784
785         The property "includes" was missing.
786         Spec: https://tc39.github.io/ecma262/#sec-array.prototype-@@unscopables
787
788         * runtime/ArrayPrototype.cpp:
789         (JSC::ArrayPrototype::finishCreation):
790         * tests/stress/unscopables.js:
791
792 2016-07-07  Saam Barati  <sbarati@apple.com>
793
794         ToThis constant folding in DFG is incorrect when the structure indicates that toThis is overridden
795         https://bugs.webkit.org/show_bug.cgi?id=159501
796         <rdar://problem/27109354>
797
798         Reviewed by Mark Lam.
799
800         We *cannot* constant fold ToThis when the structure of an object
801         indicates that toThis() is overridden. isToThisAnIdentity() inside
802         AbstractInterpreterInlines accidentally wrote the opposite rule.
803         The rule was written as we can constant fold ToThis only when
804         toThis() is overridden. To fix the bug, we must write the rule
805         as isToThisAnIdentity() can only be true as long as the structure
806         set indicates that no structures override toThis().
807
808         We could probably get more clever in the future and notice
809         when we're dealing with a constant |this| values. For example,
810         a ToThis might occur on a constant JSLexicalEnvironment. We could
811         implement the rules of JSLexicalEnvironment's toThis() implementation
812         inside AI/constant folding.
813
814         * dfg/DFGAbstractInterpreterInlines.h:
815         (JSC::DFG::isToThisAnIdentity):
816         * tests/stress/to-this-on-constant-lexical-environment.js: Added.
817         (foo.bar):
818         (foo.inner):
819         (foo):
820
821 2016-07-07  Benjamin Poulain  <benjamin@webkit.org>
822
823         [JSC] Array.prototype.includes uses ToInt32 instead of ToInteger on the index argument
824         https://bugs.webkit.org/show_bug.cgi?id=159505
825
826         Reviewed by Mark Lam.
827
828         The code was using (value)|0 which is effectively a ToInt32.
829         This fails on large integers and +-Infinity.
830
831         Spec: https://tc39.github.io/ecma262/#sec-array.prototype.includes
832
833         * builtins/ArrayPrototype.js:
834         (includes):
835
836 2016-07-07  Benjamin Poulain  <benjamin@webkit.org>
837
838         [JSC] String.prototype.normalize should have a length of zero
839         https://bugs.webkit.org/show_bug.cgi?id=159506
840
841         Reviewed by Yusuke Suzuki.
842
843         Spec: https://tc39.github.io/ecma262/#sec-string.prototype.normalize
844         The argument is optional, the length should be zero.
845
846         * runtime/StringPrototype.cpp:
847         (JSC::StringPrototype::finishCreation):
848
849 2016-07-07  Csaba Osztrogon√°c  <ossy@webkit.org>
850
851         [ARMv7] REGRESSION(r197655): ASSERTION FAILED: (cond == Zero) || (cond == NonZero)
852         https://bugs.webkit.org/show_bug.cgi?id=159419
853
854         Reviewed by Benjamin Poulain.
855
856         Allow Signed and PositiveOrZero conditions too because tst instruction updates N and Z flags.
857
858         * assembler/MacroAssemblerARM.h:
859         (JSC::MacroAssemblerARM::branchTest32):
860         * assembler/MacroAssemblerARMv7.h:
861         (JSC::MacroAssemblerARMv7::branchTest32): Add assertions to avoid possible bugs in the future.
862
863 2016-07-06  Youenn Fablet  <youenn@apple.com>
864
865         Builtin generator should use pragma once for header files
866         https://bugs.webkit.org/show_bug.cgi?id=159462
867
868         Reviewed by Alex Christensen.
869
870         * Scripts/builtins/builtins_generate_combined_header.py:
871         (BuiltinsCombinedHeaderGenerator.generate_output): 
872         * Scripts/builtins/builtins_generate_separate_header.py:
873         (BuiltinsSeparateHeaderGenerator.generate_output):
874         * Scripts/builtins/builtins_templates.py:
875         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
876         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
877         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
878         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
879         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
880         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
881         * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
882         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
883         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
884         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
885         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
886         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
887
888 2016-07-06  Benjamin Poulain  <bpoulain@apple.com>
889
890         [JSC] Unify how we throw TypeError from C++
891         https://bugs.webkit.org/show_bug.cgi?id=159500
892
893         Reviewed by Saam Barati.
894
895         Throwing a TypeError is an uncommon case. We should minimize the impact
896         on the call sites.
897
898         This patch does that by:
899         -Replace the 2 calls createTypeError()->throwException() by throwTypeError().
900         -Use ASCIILiteral when possible.
901         -Add an overload of throwTypeError() taking ASCIILiteral directly
902          (that way, the String creation and destruction is done by the callee).
903
904         On x86_64, this reduces the __TEXT__ segment by 29kb.
905
906         * inspector/JSInjectedScriptHost.cpp:
907         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
908         * inspector/JSJavaScriptCallFrame.cpp:
909         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
910         * interpreter/Interpreter.cpp:
911         (JSC::Interpreter::execute):
912         * jit/JITOperations.cpp:
913         * runtime/DatePrototype.cpp:
914         (JSC::dateProtoFuncToJSON):
915         * runtime/Error.cpp:
916         (JSC::throwConstructorCannotBeCalledAsFunctionTypeError):
917         (JSC::throwTypeError):
918         * runtime/Error.h:
919         (JSC::throwVMTypeError):
920         * runtime/JSArrayBufferPrototype.cpp:
921         (JSC::arrayBufferProtoFuncSlice):
922         * runtime/JSCJSValue.cpp:
923         (JSC::JSValue::putToPrimitive):
924         (JSC::JSValue::toStringSlowCase):
925         * runtime/JSCJSValueInlines.h:
926         (JSC::toPreferredPrimitiveType):
927         * runtime/JSDataViewPrototype.cpp:
928         (JSC::getData):
929         (JSC::setData):
930         * runtime/JSFunction.cpp:
931         (JSC::JSFunction::defineOwnProperty):
932         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
933         (JSC::constructGenericTypedArrayViewFromIterator):
934         (JSC::constructGenericTypedArrayViewWithArguments):
935         (JSC::constructGenericTypedArrayView):
936         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
937         (JSC::speciesConstruct):
938         (JSC::genericTypedArrayViewProtoFuncSet):
939         (JSC::genericTypedArrayViewProtoFuncCopyWithin):
940         (JSC::genericTypedArrayViewProtoFuncIndexOf):
941         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
942         (JSC::genericTypedArrayViewProtoFuncSubarray):
943         * runtime/JSGlobalObjectFunctions.cpp:
944         (JSC::globalFuncProtoGetter):
945         (JSC::globalFuncProtoSetter):
946         * runtime/JSONObject.cpp:
947         (JSC::Stringifier::appendStringifiedValue):
948         * runtime/JSObject.cpp:
949         (JSC::JSObject::setPrototypeWithCycleCheck):
950         (JSC::callToPrimitiveFunction):
951         (JSC::JSObject::ordinaryToPrimitive):
952         (JSC::JSObject::defaultHasInstance):
953         (JSC::validateAndApplyPropertyDescriptor):
954         * runtime/JSTypedArrayViewConstructor.cpp:
955         (JSC::constructTypedArrayView):
956         * runtime/JSTypedArrayViewPrototype.cpp:
957         (JSC::typedArrayViewPrivateFuncLength):
958         (JSC::typedArrayViewProtoFuncSet):
959         (JSC::typedArrayViewProtoFuncCopyWithin):
960         (JSC::typedArrayViewProtoFuncFill):
961         (JSC::typedArrayViewProtoFuncLastIndexOf):
962         (JSC::typedArrayViewProtoFuncIndexOf):
963         (JSC::typedArrayViewProtoFuncJoin):
964         (JSC::typedArrayViewProtoGetterFuncBuffer):
965         (JSC::typedArrayViewProtoGetterFuncLength):
966         (JSC::typedArrayViewProtoGetterFuncByteLength):
967         (JSC::typedArrayViewProtoGetterFuncByteOffset):
968         (JSC::typedArrayViewProtoFuncReverse):
969         (JSC::typedArrayViewProtoFuncSubarray):
970         (JSC::typedArrayViewProtoFuncSlice):
971         * runtime/ObjectConstructor.cpp:
972         (JSC::toPropertyDescriptor):
973         (JSC::objectConstructorDefineProperty):
974         (JSC::objectConstructorDefineProperties):
975         (JSC::objectConstructorCreate):
976         * runtime/ObjectPrototype.cpp:
977         (JSC::objectProtoFuncDefineGetter):
978         (JSC::objectProtoFuncDefineSetter):
979         * runtime/RegExpPrototype.cpp:
980         (JSC::regExpProtoFuncCompile):
981         * runtime/Symbol.cpp:
982         (JSC::Symbol::toNumber):
983
984 2016-07-06  Saam Barati  <sbarati@apple.com>
985
986         InlineAccess::sizeForLengthAccess() is wrong on some platforms because it should also consider "length" not being array length
987         https://bugs.webkit.org/show_bug.cgi?id=159429
988
989         Reviewed by Filip Pizlo.
990
991         The calculation inside sizeForLengthAccess() was not taking into
992         account that an access to a "length" property might not be an
993         array length access. sizeForLengthAccess() should always have enough
994         room for a regular self property accesses. This only changes how
995         much of a nop sled we emit if array length access size is smaller
996         than self access size. This matters on ARM64.
997
998         * bytecode/InlineAccess.h:
999         (JSC::InlineAccess::sizeForPropertyAccess):
1000         (JSC::InlineAccess::sizeForPropertyReplace):
1001         (JSC::InlineAccess::sizeForLengthAccess):
1002
1003 2016-07-06  Commit Queue  <commit-queue@webkit.org>
1004
1005         Unreviewed, rolling out r198928 and r198985.
1006         https://bugs.webkit.org/show_bug.cgi?id=159478
1007
1008         "It's breaking some websites" (Requested by saamyjoon on
1009         #webkit).
1010
1011         Reverted changesets:
1012
1013         "[ES6] Disallow var assignments in for-in loops"
1014         https://bugs.webkit.org/show_bug.cgi?id=155451
1015         http://trac.webkit.org/changeset/198928
1016
1017         "Unreviewed, turn ES6 for-in loop test success"
1018         https://bugs.webkit.org/show_bug.cgi?id=155451
1019         http://trac.webkit.org/changeset/198985
1020
1021 2016-07-05  Mark Lam  <mark.lam@apple.com>
1022
1023         Rename VM stack limit fields to better describe their purpose.
1024         https://bugs.webkit.org/show_bug.cgi?id=159451
1025
1026         Reviewed by Keith Miller.
1027
1028         This is in preparation for an upcoming patch that changes what stack limit values
1029         are used under various circumstances.  This patch aims to do some minimal work to
1030         rename the fields so that it will be easier to reason about the upcoming patch.
1031     
1032         In this patch, we make the following changes:
1033
1034         1. Rename VM::m_stackLimit to VM::m_jsCPUStackLimit.
1035
1036         2. VM::m_jsStackLimit used to have an overloaded meaning:
1037            a. For JIT builds, m_jsStackLimit is synonymous with m_stackLimit.
1038            b. For C Loop builds, m_jsStackLimit is a separate pointer that points to the
1039               emulated JS stack that the C Loop uses.
1040
1041            In place of m_jsStackLimit, this patch introduces 2 new fields:
1042            VM::m_jsEmulatedStackLimit and VM::m_llintStackLimit.
1043
1044            m_llintStackLimit is the limit that the LLInt assembly uses for its stack
1045            check.  m_llintStackLimit behaves like the old m_jsStackLimit in that:
1046            a. For JIT builds, m_llintStackLimit is synonymous with m_jsCPUStackLimit.
1047            b. For C Loop builds, m_llintStackLimit is synonymous with m_jsEmulatedStackLimit.
1048
1049            m_jsEmulatedStackLimit is used for the emulated stack that the C Loop uses.
1050
1051         3. Rename the following methods to match the above:
1052              VM::stackLimit() ==> VM::jsCPUStackLimit()
1053              VM::addressOfStackLimit() ==> VM::addressOfJSCPUStackLimit()
1054              VM::jsStackLimit() ==> VM::jsEmulatedStackLimit()
1055              VM::setJSStackLimit() ==> VM::setJSEmulatedStackLimit()
1056              JSStack::setStackLimit() ==> JSStack::setEmulatedStackLimit()
1057
1058         4. With change (2) and (3), the limits will be used as follows:
1059            a. VM code doing stack recursion checks will only use m_jsCPUStackLimit.
1060            b. JIT code will only use m_jsCPUStackLimit.
1061            c. C Loop emulated stack code in JSStack will only use m_jsEmulatedStackLimit.
1062               Note: the part of JSStack that operates on a JIT build will use
1063                     m_jsCPUStackLimit as expected.
1064            d. LLINT assembly code will only use m_llintStackLimit.
1065
1066         This patch only contains the above refactoring changes.  There is no behavior
1067         change.
1068
1069         * dfg/DFGJITCompiler.cpp:
1070         (JSC::DFG::JITCompiler::compile):
1071         (JSC::DFG::JITCompiler::compileFunction):
1072         * ftl/FTLLowerDFGToB3.cpp:
1073         (JSC::FTL::DFG::LowerDFGToB3::lower):
1074         * interpreter/JSStack.cpp:
1075         (JSC::JSStack::JSStack):
1076         (JSC::JSStack::growSlowCase):
1077         (JSC::JSStack::lowAddress):
1078         (JSC::JSStack::highAddress):
1079         * interpreter/JSStack.h:
1080         * interpreter/JSStackInlines.h:
1081         (JSC::JSStack::ensureCapacityFor):
1082         (JSC::JSStack::shrink):
1083         (JSC::JSStack::grow):
1084         (JSC::JSStack::setJSEmulatedStackLimit):
1085         (JSC::JSStack::setStackLimit): Deleted.
1086         * jit/JIT.cpp:
1087         (JSC::JIT::compileWithoutLinking):
1088         * jit/SetupVarargsFrame.cpp:
1089         (JSC::emitSetupVarargsFrameFastCase):
1090         * llint/LLIntSlowPaths.cpp:
1091         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1092         * llint/LowLevelInterpreter.asm:
1093         * llint/LowLevelInterpreter32_64.asm:
1094         * llint/LowLevelInterpreter64.asm:
1095         * runtime/RegExp.cpp:
1096         (JSC::RegExp::finishCreation):
1097         (JSC::RegExp::compile):
1098         (JSC::RegExp::compileMatchOnly):
1099         * runtime/VM.cpp:
1100         (JSC::VM::VM):
1101         (JSC::VM::updateStackLimit):
1102         * runtime/VM.h:
1103         (JSC::VM::reservedZoneSize):
1104         (JSC::VM::jsCPUStackLimit):
1105         (JSC::VM::addressOfJSCPUStackLimit):
1106         (JSC::VM::jsEmulatedStackLimit):
1107         (JSC::VM::setJSEmulatedStackLimit):
1108         (JSC::VM::isSafeToRecurse):
1109         (JSC::VM::jsStackLimit): Deleted.
1110         (JSC::VM::setJSStackLimit): Deleted.
1111         (JSC::VM::stackLimit): Deleted.
1112         (JSC::VM::addressOfStackLimit): Deleted.
1113         * wasm/WASMFunctionCompiler.h:
1114         (JSC::WASMFunctionCompiler::startFunction):
1115
1116 2016-07-05  Saam Barati  <sbarati@apple.com>
1117
1118         StackVisitor::unwindToMachineCodeBlockFrame() may unwind past a VM entry frame when catching an exception and the frame has inlined tail calls
1119         https://bugs.webkit.org/show_bug.cgi?id=159448
1120         <rdar://problem/27084459>
1121
1122         Reviewed by Mark Lam.
1123
1124         Consider the following stack trace:
1125         (machine) foo -> VM entry frame -> (machine) bar -> (inlined tailcall) baz
1126
1127         If an exception is thrown at 'baz', we will do exception unwinding,
1128         which will eventually call unwindToMachineCodeBlockFrame() which will call
1129         gotoNextFrame() on the 'baz' frame. The next logical frame for 'baz' is 'foo' because
1130         'bar' tail called 'baz' even though there is a machine frame for 'bar' on the stack.
1131         This is a bug. unwindToMachineCodeBlockFrame() should not care about the next
1132         logical frame, it just wants to move StackVisitor's state to the current machine
1133         frame. The bug here is that we would end up unwinding past the VM entry frame
1134         which can have all kinds of terrible consequences.
1135
1136         This bug fixes unwindToMachineCodeBlockFrame() by having it not rely
1137         on gotoNextFrame() and instead using its own mechanism for setting
1138         the StackVisotor's state to the current machine frame.
1139
1140         * interpreter/StackVisitor.cpp:
1141         (JSC::StackVisitor::unwindToMachineCodeBlockFrame):
1142         * tests/stress/dont-unwind-past-vm-entry-frame.js: Added.
1143         (let.p.new.Proxy):
1144         (let.p.new.Proxy.apply):
1145         (bar):
1146         (let.good):
1147         (getItem):
1148         (start):
1149
1150 2016-07-05  Joseph Pecoraro  <pecoraro@apple.com>
1151
1152         RELEASE_ASSERT(!thisObject) in ObjCCallbackFunctionImpl::call when calling JSExport ObjC Constructor without operator new
1153         https://bugs.webkit.org/show_bug.cgi?id=159446
1154
1155         Reviewed by Mark Lam.
1156
1157         Treat ObjC JSExport init constructors like ES6 Class Constructors
1158         and throw a TypeError when called without 'new'.
1159
1160         * API/ObjCCallbackFunction.mm:
1161         (JSC::ObjCCallbackFunctionImpl::type):
1162         (JSC::objCCallbackFunctionCallAsFunction):
1163         When calling an init method as a function instead of construction
1164         throw a TypeError.
1165
1166         * bytecompiler/BytecodeGenerator.cpp:
1167         (JSC::BytecodeGenerator::BytecodeGenerator):
1168         Improve error message.
1169
1170         * API/tests/testapi.mm:
1171         (testObjectiveCAPIMain):
1172         Test we get an exception when calling an ObjC constructor without 'new'.
1173
1174 2016-07-05  Mark Lam  <mark.lam@apple.com>
1175
1176         Remove some unneeded #include "CachedCall.h".
1177         https://bugs.webkit.org/show_bug.cgi?id=159449
1178
1179         Reviewed by Saam Barati.
1180
1181         * runtime/ArrayPrototype.cpp:
1182         * runtime/JSArray.cpp:
1183         * runtime/MapPrototype.cpp:
1184         * runtime/SetPrototype.cpp:
1185
1186 2016-07-05  Geoffrey Garen  <ggaren@apple.com>
1187
1188         Crash @ bankofamerica.com, University of Vienna
1189         https://bugs.webkit.org/show_bug.cgi?id=159439
1190
1191         Reviewed by Saam Barati.
1192
1193         * ftl/FTLLink.cpp:
1194         (JSC::FTL::link): Do check for stack overflow in the arity mismatch thunk
1195         because it can happen. Don't store a CallSiteIndex because we haven't
1196         stored a CodeBlock yet, and our stack frame is not fully constructed,
1197         so it would be an error for any client to try to load this value (and
1198         operationCallArityCheck does not load this value).
1199
1200         * tests/stress/arity-check-ftl-throw.js: Added. New test case for stressing
1201         a stack overflow with arity mismatch. Sadly, after hours of fiddling, I
1202         can't seem to get this to fail in trunk. Still, it's good to have some
1203         more testing in this area.
1204
1205 2016-07-05  Benjamin Poulain  <bpoulain@apple.com>
1206
1207         [JSC] The prototype cycle checks throws the wrong error type
1208         https://bugs.webkit.org/show_bug.cgi?id=159393
1209
1210         Reviewed by Geoffrey Garen.
1211
1212         We were supposed to throw the TypeError:
1213         -https://tc39.github.io/ecma262/#sec-set-object.prototype.__proto__
1214
1215         * runtime/JSObject.cpp:
1216         (JSC::JSObject::setPrototypeWithCycleCheck):
1217
1218 2016-07-05  Saam Barati  <sbarati@apple.com>
1219
1220         our parsing for "use strict" is wrong when we first parse other directives that are not "use strict" but are located in a place where "use strict" would be valid
1221         https://bugs.webkit.org/show_bug.cgi?id=159376
1222         <rdar://problem/27108773>
1223
1224         Reviewed by Benjamin Poulain.
1225
1226         Our strict mode detection algorithm used to break if we ever saw a directive
1227         that is not "use strict" but is syntactically located in a location where our
1228         parser looks for "use strict". It broke as follows:
1229
1230         If a function started with a non "use strict" string literal, we will allow
1231         "use strict" to be in any arbitrary statement inside the top level block in
1232         the function body. For example, this meant that if we parsed a sequence of string
1233         literals, followed by arbitrary statements, followed by "use strict", we would parse
1234         the function as if it's in strict mode. This is the wrong behavior with respect to
1235         the spec. This has consequences in other ways that break invariants of the language.
1236         For example, we used to allow functions that are lexically nested inside what we deemed
1237         a strict function to be non-strict. This used to fire an assertion if we ever skipped over
1238         that function using the source provider cache, but it worked just fine in release builds.
1239
1240         This patch fixes this bug.
1241
1242         * parser/Parser.cpp:
1243         (JSC::Parser<LexerType>::parseSourceElements):
1244         (JSC::Parser<LexerType>::parseStatement):
1245         * tests/stress/ensure-proper-strict-mode-parsing.js: Added.
1246         (foo.bar):
1247         (foo):
1248         (bar.foo):
1249         (bar):
1250         (bar.call.undefined.this.throw.new.Error.string_appeared_here.baz):
1251         (baz.call.undefined.undefined.throw.new.Error.string_appeared_here.jaz):
1252         (jaz.call.undefined.this.throw.new.Error.string_appeared_here.vaz):
1253
1254 2016-07-05  Saam Barati  <sbarati@apple.com>
1255
1256         reportAbandonedObjectGraph should report abandoned bytes based on capacity() so it works even if a GC has never happened
1257         https://bugs.webkit.org/show_bug.cgi?id=159222
1258         <rdar://problem/27001991>
1259
1260         Reviewed by Geoffrey Garen.
1261
1262         When reportAbandonedObjectGraph() was called before the first GC, it used to
1263         not indicate to the GC timers that we have memory that needs to be collected
1264         because the calculation was based on m_sizeAfterLastCollect (which was zero).
1265         This patch makes the calculation based on capacity() which is a valid number
1266         even before the first GC.
1267
1268         * heap/Heap.cpp:
1269         (JSC::Heap::reportAbandonedObjectGraph):
1270         (JSC::Heap::protect):
1271         (JSC::Heap::didAbandon): Deleted.
1272         * heap/Heap.h:
1273         (JSC::Heap::jitStubRoutines):
1274
1275 2016-07-05  Csaba Osztrogon√°c  <ossy@webkit.org>
1276
1277         Typo fix after r202214
1278         https://bugs.webkit.org/show_bug.cgi?id=159416
1279
1280         Reviewed by Saam Barati.
1281
1282         * bytecode/InlineAccess.h:
1283
1284 2016-07-03  Per Arne Vollan  <pvollan@apple.com>
1285
1286         [Win] DLLs are missing version information.
1287         https://bugs.webkit.org/show_bug.cgi?id=159349
1288
1289         Reviewed by Brent Fulgham.
1290
1291         Run perl version stamp utility.
1292         
1293         * CMakeLists.txt:
1294
1295 2016-07-01  Yusuke Suzuki  <utatane.tea@gmail.com>
1296
1297         [JSC] MacroAssemblerX86::branch8 should accept unsigned 8bit value
1298         https://bugs.webkit.org/show_bug.cgi?id=159334
1299
1300         Reviewed by Benjamin Poulain.
1301
1302         As described in branchTest8 functions, byte in TrustedImm32 is not well defined.
1303         So the assertion here should be a little permissive; accepting -128 to 255.
1304
1305         This assertion is originally fired when executing misc-bugs-847389-jpeg2000 benchmark in Debug build.
1306         So this patch includes misc-bugs-847389-jpeg2000 benchmark.
1307
1308         * assembler/MacroAssemblerX86Common.h:
1309         (JSC::MacroAssemblerX86Common::branchTest8):
1310         (JSC::MacroAssemblerX86Common::branch8):
1311         * b3/testb3.cpp:
1312         (JSC::B3::testBranch8WithLoad8ZIndex):
1313         (JSC::B3::run):
1314
1315 2016-07-03  Benjamin Poulain  <bpoulain@apple.com>
1316
1317         [JSC] __lookupGetter__ and __lookupSetter__ should not ignore exceptions
1318         https://bugs.webkit.org/show_bug.cgi?id=159390
1319
1320         Reviewed by Mark Lam.
1321
1322         See:
1323         -https://tc39.github.io/ecma262/#sec-object.prototype.__lookupGetter__
1324         -https://tc39.github.io/ecma262/#sec-object.prototype.__lookupSetter__
1325
1326         They are both supposed to be regular [[GetOwnProperty]].
1327
1328         * runtime/ObjectPrototype.cpp:
1329         (JSC::objectProtoFuncLookupGetter):
1330         (JSC::objectProtoFuncLookupSetter):
1331
1332 2016-07-03  Saam Barati  <sbarati@apple.com>
1333
1334         BytecodeGenerator::getVariablesUnderTDZ is too conservative
1335         https://bugs.webkit.org/show_bug.cgi?id=159387
1336
1337         Reviewed by Filip Pizlo.
1338
1339         We were too conservative in the following type of programs:
1340         ```
1341         {
1342             {
1343                 let x;
1344                 ...
1345             }
1346             let x;
1347         }
1348         ```
1349         We used to report "x" as under TDZ when calling getVariablesUnderTDZ at the
1350         "...", even though "x" is not under TDZ. This patch removes this conservatism
1351         and makes the algorithm precise.
1352
1353         * bytecompiler/BytecodeGenerator.cpp:
1354         (JSC::BytecodeGenerator::getVariablesUnderTDZ):
1355         * bytecompiler/BytecodeGenerator.h:
1356
1357 2016-07-03  Filip Pizlo  <fpizlo@apple.com>
1358
1359         FTL should refer to B3 types directly
1360         https://bugs.webkit.org/show_bug.cgi?id=159389
1361
1362         Reviewed by Saam Barati.
1363         
1364         When we used LLVM, types were objects that were allocated by the LLVMContext. We had to
1365         remember pointers to them or else call through the C API every time we wanted the type. We
1366         stored the type pointers inside FTL::CommonValues.
1367         
1368         But in B3, types are just members of an enum. We don't have to remember pointers to them.
1369         
1370         This change replaces all prior uses of things like "m_out.int32" with just "Int32", and
1371         likewise for m_out.boolean, m_out.int64, m_out.intPtr, m_out.floatType, m_out.doubleType,
1372         and m_out.voidType.
1373         
1374         We still use FTL::CommonValues for common constants that we have pre-hoisted. Hopefully we
1375         will come up with a better story for those eventually, since that's still kinda ugly.
1376
1377         * ftl/FTLCommonValues.cpp:
1378         (JSC::FTL::CommonValues::CommonValues):
1379         * ftl/FTLCommonValues.h:
1380         * ftl/FTLLowerDFGToB3.cpp:
1381         (JSC::FTL::DFG::LowerDFGToB3::createPhiVariables):
1382         (JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep):
1383         (JSC::FTL::DFG::LowerDFGToB3::compileBooleanToNumber):
1384         (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
1385         (JSC::FTL::DFG::LowerDFGToB3::compileToThis):
1386         (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
1387         (JSC::FTL::DFG::LowerDFGToB3::compileStrCat):
1388         (JSC::FTL::DFG::LowerDFGToB3::compileArithMinOrMax):
1389         (JSC::FTL::DFG::LowerDFGToB3::compileArithPow):
1390         (JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
1391         (JSC::FTL::DFG::LowerDFGToB3::compileArrayifyToStructure):
1392         (JSC::FTL::DFG::LowerDFGToB3::compileGetById):
1393         (JSC::FTL::DFG::LowerDFGToB3::compileGetByIdWithThis):
1394         (JSC::FTL::DFG::LowerDFGToB3::compileGetByValWithThis):
1395         (JSC::FTL::DFG::LowerDFGToB3::compilePutByIdWithThis):
1396         (JSC::FTL::DFG::LowerDFGToB3::compilePutByValWithThis):
1397         (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
1398         (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
1399         (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
1400         (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
1401         (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
1402         (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
1403         (JSC::FTL::DFG::LowerDFGToB3::compilePutAccessorById):
1404         (JSC::FTL::DFG::LowerDFGToB3::compilePutGetterSetterById):
1405         (JSC::FTL::DFG::LowerDFGToB3::compilePutAccessorByVal):
1406         (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):
1407         (JSC::FTL::DFG::LowerDFGToB3::compileArrayPop):
1408         (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
1409         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
1410         (JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
1411         (JSC::FTL::DFG::LowerDFGToB3::compileCreateScopedArguments):
1412         (JSC::FTL::DFG::LowerDFGToB3::compileCreateClonedArguments):
1413         (JSC::FTL::DFG::LowerDFGToB3::compileCopyRest):
1414         (JSC::FTL::DFG::LowerDFGToB3::compileGetRestLength):
1415         (JSC::FTL::DFG::LowerDFGToB3::compileNewObject):
1416         (JSC::FTL::DFG::LowerDFGToB3::compileNewArray):
1417         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer):
1418         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
1419         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
1420         (JSC::FTL::DFG::LowerDFGToB3::compileToNumber):
1421         (JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructor):
1422         (JSC::FTL::DFG::LowerDFGToB3::compileToPrimitive):
1423         (JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
1424         (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
1425         (JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):
1426         (JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
1427         (JSC::FTL::DFG::LowerDFGToB3::compileGetByOffset):
1428         (JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset):
1429         (JSC::FTL::DFG::LowerDFGToB3::compilePutByOffset):
1430         (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
1431         (JSC::FTL::DFG::LowerDFGToB3::compileLoadVarargs):
1432         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
1433         (JSC::FTL::DFG::LowerDFGToB3::compileSwitch):
1434         (JSC::FTL::DFG::LowerDFGToB3::compileIsString):
1435         (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray):
1436         (JSC::FTL::DFG::LowerDFGToB3::compileIsObject):
1437         (JSC::FTL::DFG::LowerDFGToB3::compileIsObjectOrNull):
1438         (JSC::FTL::DFG::LowerDFGToB3::compileIsFunction):
1439         (JSC::FTL::DFG::LowerDFGToB3::compileIsRegExpObject):
1440         (JSC::FTL::DFG::LowerDFGToB3::compileIsTypedArrayView):
1441         (JSC::FTL::DFG::LowerDFGToB3::compileTypeOf):
1442         (JSC::FTL::DFG::LowerDFGToB3::compileIn):
1443         (JSC::FTL::DFG::LowerDFGToB3::compileOverridesHasInstance):
1444         (JSC::FTL::DFG::LowerDFGToB3::compileCheckTypeInfoFlags):
1445         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
1446         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOfCustom):
1447         (JSC::FTL::DFG::LowerDFGToB3::compileCountExecution):
1448         (JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty):
1449         (JSC::FTL::DFG::LowerDFGToB3::compileHasGenericProperty):
1450         (JSC::FTL::DFG::LowerDFGToB3::compileHasStructureProperty):
1451         (JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname):
1452         (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumerableLength):
1453         (JSC::FTL::DFG::LowerDFGToB3::compileGetPropertyEnumerator):
1454         (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumeratorStructurePname):
1455         (JSC::FTL::DFG::LowerDFGToB3::compileGetEnumeratorGenericPname):
1456         (JSC::FTL::DFG::LowerDFGToB3::compileToIndexString):
1457         (JSC::FTL::DFG::LowerDFGToB3::compileCheckStructureImmediate):
1458         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
1459         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
1460         (JSC::FTL::DFG::LowerDFGToB3::compileSetFunctionName):
1461         (JSC::FTL::DFG::LowerDFGToB3::numberOrNotCellToInt32):
1462         (JSC::FTL::DFG::LowerDFGToB3::checkInferredType):
1463         (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
1464         (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
1465         (JSC::FTL::DFG::LowerDFGToB3::reallocatePropertyStorage):
1466         (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorageWithSizeImpl):
1467         (JSC::FTL::DFG::LowerDFGToB3::getById):
1468         (JSC::FTL::DFG::LowerDFGToB3::compare):
1469         (JSC::FTL::DFG::LowerDFGToB3::compileResolveScope):
1470         (JSC::FTL::DFG::LowerDFGToB3::compileGetDynamicVar):
1471         (JSC::FTL::DFG::LowerDFGToB3::compareEqObjectOrOtherToObject):
1472         (JSC::FTL::DFG::LowerDFGToB3::speculateTruthyObject):
1473         (JSC::FTL::DFG::LowerDFGToB3::nonSpeculativeCompare):
1474         (JSC::FTL::DFG::LowerDFGToB3::stringsEqual):
1475         (JSC::FTL::DFG::LowerDFGToB3::allocateVariableSizedObject):
1476         (JSC::FTL::DFG::LowerDFGToB3::allocateObject):
1477         (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
1478         (JSC::FTL::DFG::LowerDFGToB3::ensureShadowChickenPacket):
1479         (JSC::FTL::DFG::LowerDFGToB3::boolify):
1480         (JSC::FTL::DFG::LowerDFGToB3::equalNullOrUndefined):
1481         (JSC::FTL::DFG::LowerDFGToB3::contiguousPutByValOutOfBounds):
1482         (JSC::FTL::DFG::LowerDFGToB3::buildSwitch):
1483         (JSC::FTL::DFG::LowerDFGToB3::switchStringSlow):
1484         (JSC::FTL::DFG::LowerDFGToB3::doubleToInt32):
1485         (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
1486         (JSC::FTL::DFG::LowerDFGToB3::strictInt52ToJSValue):
1487         (JSC::FTL::DFG::LowerDFGToB3::strictInt52ToInt52):
1488         (JSC::FTL::DFG::LowerDFGToB3::unboxInt32):
1489         (JSC::FTL::DFG::LowerDFGToB3::boxInt32):
1490         (JSC::FTL::DFG::LowerDFGToB3::isCellOrMisc):
1491         (JSC::FTL::DFG::LowerDFGToB3::unboxDouble):
1492         (JSC::FTL::DFG::LowerDFGToB3::boxDouble):
1493         (JSC::FTL::DFG::LowerDFGToB3::jsValueToStrictInt52):
1494         (JSC::FTL::DFG::LowerDFGToB3::doubleToStrictInt52):
1495         (JSC::FTL::DFG::LowerDFGToB3::convertDoubleToInt32):
1496         (JSC::FTL::DFG::LowerDFGToB3::callCheck):
1497         (JSC::FTL::DFG::LowerDFGToB3::crash):
1498         * ftl/FTLOutput.cpp:
1499         (JSC::FTL::Output::bitCast):
1500
1501 2016-07-02  Filip Pizlo  <fpizlo@apple.com>
1502
1503         DFG LICM needs to go all-in on the idea that some loops can't be LICMed
1504         https://bugs.webkit.org/show_bug.cgi?id=159388
1505
1506         Reviewed by Mark Lam.
1507         
1508         Some time ago I acknowledged that LICM required loops to meet certain requirements that
1509         may get broken by the time we do LICM, like that the terminal of the pre-header is ExitOK.
1510         It used to be that we just ignored that requirement and would hoist anyway, but since
1511         r189126 we've stopped hoisting out of loops that don't have ExitOK.  We also added tests
1512         for the case that the pre-header doesn't exist or is invalid.
1513
1514         It turns out that this patch didn't go far enough: even though it made LICM avoid loops
1515         that had an invalid pre-header, the part that updated the AI state in nested loops still
1516         assumed that these loops had valid pre-headers.  We would crash in null dereference in
1517         that loop if a nested loop had an invalid pre-header.
1518
1519         The fix is simple: don't update the AI state of nested loops that don't have pre-headers,
1520         since we won't try to hoist out of those loops anyway.
1521
1522         * dfg/DFGLICMPhase.cpp:
1523         (JSC::DFG::LICMPhase::attemptHoist):
1524         * tests/stress/licm-no-pre-header-nested.js: Added. This would always crash before this fix.
1525         (foo):
1526         * tests/stress/licm-pre-header-cannot-exit-nested.js: Added. This was a failed attempt at a test, but I figure it's good to have weird code anyway.
1527         (foo):
1528         (valueOf):
1529
1530 2016-06-30  Filip Pizlo  <fpizlo@apple.com>
1531
1532         Scopes that are not under TDZ should still push their variables onto the TDZ stack so that lifting TDZ doesn't bypass that scope
1533         https://bugs.webkit.org/show_bug.cgi?id=159332
1534         rdar://problem/27018958
1535
1536         Reviewed by Saam Barati.
1537         
1538         This fixes an instacrash in this code:
1539         
1540             try{}catch(e){}print(e);let e;
1541         
1542         We lift TDZ for "e" in "catch (e){}", but since that scope doesn't push anything onto the
1543         TDZ stack, we lift TDZ from "let e".
1544         
1545         The problem is that we weren't tracking the set of variables that do not have TDZ. We need
1546         to track them to "block" the traversal that lifts TDZ. This change fixes this issue by
1547         using a map that tracks all known variables, and tells you if they are under TDZ or not.
1548
1549         * bytecode/CodeBlock.h:
1550         (JSC::CodeBlock::numParameters):
1551         * bytecode/CodeOrigin.h:
1552         * bytecompiler/BytecodeGenerator.cpp:
1553         (JSC::Label::setLocation):
1554         (JSC::Variable::dump):
1555         (JSC::BytecodeGenerator::generate):
1556         (JSC::BytecodeGenerator::BytecodeGenerator):
1557         (JSC::BytecodeGenerator::pushLexicalScopeInternal):
1558         (JSC::BytecodeGenerator::popLexicalScope):
1559         (JSC::BytecodeGenerator::popLexicalScopeInternal):
1560         (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
1561         (JSC::BytecodeGenerator::variable):
1562         (JSC::BytecodeGenerator::needsTDZCheck):
1563         (JSC::BytecodeGenerator::liftTDZCheckIfPossible):
1564         (JSC::BytecodeGenerator::pushTDZVariables):
1565         (JSC::BytecodeGenerator::getVariablesUnderTDZ):
1566         (JSC::BytecodeGenerator::endGenerator):
1567         (WTF::printInternal):
1568         * bytecompiler/BytecodeGenerator.h:
1569         (JSC::Variable::isConst):
1570         (JSC::Variable::setIsReadOnly):
1571         * interpreter/CallFrame.h:
1572         (JSC::ExecState::topOfFrame):
1573         * tests/stress/lift-tdz-bypass-catch.js: Added.
1574         (foo):
1575         (catch):
1576
1577 2016-07-01  Benjamin Poulain  <bpoulain@apple.com>
1578
1579         [JSC] RegExp.compile is not returning the regexp when it succeed
1580         https://bugs.webkit.org/show_bug.cgi?id=159381
1581
1582         Reviewed by Mark Lam.
1583
1584         Spec:
1585         -https://tc39.github.io/ecma262/#sec-regexp.prototype.compile
1586         -https://tc39.github.io/ecma262/#sec-regexpinitialize
1587
1588         * runtime/RegExpPrototype.cpp:
1589         (JSC::regExpProtoFuncCompile):
1590
1591 2016-07-01  Saam Barati  <sbarati@apple.com>
1592
1593         fix "ASSERTION FAILED: currentOffset() >= currentLineStartOffset()"
1594         https://bugs.webkit.org/show_bug.cgi?id=158572
1595         <rdar://problem/26884092>
1596
1597         Reviewed by Mark Lam.
1598
1599         There is a bug in our lexer when we notice the pattern:
1600         ```<return|continue|break|...etc> // some comment here```
1601         Our code will say that the token for the comment is a semicolon.
1602         This is the correct semantics, however, it would give the semicolon
1603         a start offset of the comment, but it will give its line start offset
1604         the newline after the comment.  This breaks the invariant in the lexer/parser
1605         that the offset for the current line starting point must be less than or equal to
1606         than the start offset of any token on that line. This invariant was broken because
1607         the line start offset was greater than the token start offset. To maintain this
1608         invariant, we claim that the semicolon token is located where the comment starts,
1609         and that its line start offset is the line start offset for the line with the
1610         comment on it.  There are other solutions that maintain this invariant, but this
1611         solution provides the best error messages.
1612
1613         * parser/Lexer.cpp:
1614         (JSC::Lexer<T>::lex):
1615         * parser/Parser.h:
1616         (JSC::Parser::internalSaveLexerState):
1617         * tests/stress/obscure-error-message-dont-crash.js: Added.
1618         (try.eval.or.catch):
1619
1620 2016-07-01  Benjamin Poulain  <bpoulain@apple.com>
1621
1622         __defineGetter__/__defineSetter__ should throw exceptions
1623         https://bugs.webkit.org/show_bug.cgi?id=142934
1624
1625         Reviewed by Mark Lam.
1626
1627         * runtime/ObjectPrototype.cpp:
1628         (JSC::objectProtoFuncDefineGetter):
1629         (JSC::objectProtoFuncDefineSetter):
1630
1631 2016-07-01  Jon Davis  <jond@apple.com>
1632
1633         Moved Web Animations and Resource Timing feature entries to WebCore.
1634         https://bugs.webkit.org/show_bug.cgi?id=159356
1635
1636         Reviewed by Timothy Hatcher.
1637
1638         * features.json:
1639
1640 2016-07-01  Benjamin Poulain  <bpoulain@apple.com>
1641
1642         [JSC] Date.toGMTString should be the Date.toUTCString function
1643         https://bugs.webkit.org/show_bug.cgi?id=159318
1644
1645         Reviewed by Mark Lam.
1646
1647         See https://tc39.github.io/ecma262/#sec-date.prototype.togmtstring
1648
1649         * runtime/DatePrototype.cpp:
1650         (JSC::DatePrototype::finishCreation):
1651         (JSC::dateProtoFuncToGMTString): Deleted.
1652
1653 2016-07-01  Mark Lam  <mark.lam@apple.com>
1654
1655         Update JSC_functionOverrides to handle the new SourceCode strings that have params.
1656         https://bugs.webkit.org/show_bug.cgi?id=159321
1657
1658         Reviewed by Geoffrey Garen.
1659
1660         And add tests so that this won't fail silently and bit rot anymore.
1661
1662         * API/tests/FunctionOverridesTest.cpp: Added.
1663         (testFunctionOverrides):
1664         * API/tests/FunctionOverridesTest.h: Added.
1665         * API/tests/testapi-function-overrides.js: Added.
1666         * API/tests/testapi.c:
1667         (main):
1668         * JavaScriptCore.xcodeproj/project.pbxproj:
1669         * bytecode/UnlinkedFunctionExecutable.cpp:
1670         (JSC::UnlinkedFunctionExecutable::link):
1671         * shell/PlatformWin.cmake:
1672         * tools/FunctionOverrides.cpp:
1673         (JSC::FunctionOverrides::FunctionOverrides):
1674         (JSC::FunctionOverrides::reinstallOverrides):
1675         (JSC::initializeOverrideInfo):
1676         (JSC::FunctionOverrides::initializeOverrideFor):
1677         * tools/FunctionOverrides.h:
1678         (JSC::FunctionOverrides::clear):
1679
1680 2016-07-01  Caio Lima  <ticaiolima@gmail.com>
1681
1682         ES6: Implement HasRestrictedGlobalProperty when checking for global lexical tier conflicts
1683         https://bugs.webkit.org/show_bug.cgi?id=148763
1684
1685         Reviewed by Saam Barati
1686
1687         I've implemented the ES6 spec 8.1.1.4.14
1688         (http://www.ecma-international.org/ecma-262/6.0/index.html#sec-hasrestrictedglobalproperty)
1689         that defines when a global property can be shadowed.
1690
1691         Added some test cases into global-lexical-redeclare-variable.js
1692
1693         * runtime/Executable.cpp:
1694         (JSC::ProgramExecutable::initializeGlobalProperties):
1695         * tests/stress/global-lexical-redeclare-variable.js:
1696         (catch):
1697         * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/eighth.js: Added.
1698         * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/nineth.js: Added.
1699         * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/seventh.js: Added.
1700         * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/sixth.js:
1701         * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/tenth.js: Added.
1702
1703 2016-07-01  Youenn Fablet  <youennf@gmail.com>
1704
1705         Add a runtime flag for DOM iterators
1706         https://bugs.webkit.org/show_bug.cgi?id=159300
1707
1708         Reviewed by Alex Christensen.
1709
1710         * runtime/CommonIdentifiers.h:
1711
1712 2016-06-30  Joseph Pecoraro  <pecoraro@apple.com>
1713
1714         Web Inspector: Wrong function name next to scope
1715         https://bugs.webkit.org/show_bug.cgi?id=158210
1716         <rdar://problem/26543093>
1717
1718         Reviewed by Timothy Hatcher.
1719
1720         * CMakeLists.txt:
1721         * JavaScriptCore.xcodeproj/project.pbxproj:
1722         Add DebuggerLocation. A helper for describing a unique location.
1723
1724         * bytecode/CodeBlock.cpp:
1725         (JSC::CodeBlock::setConstantRegisters):
1726         When compiled with debug info, add a SymbolTable rare data pointer
1727         back to the CodeBlock. This will be used later to get JSScope debug
1728         info if Web Inspector pauses.
1729
1730         * runtime/SymbolTable.h:
1731         * runtime/SymbolTable.cpp:
1732         (JSC::SymbolTable::cloneScopePart):
1733         (JSC::SymbolTable::prepareForTypeProfiling):
1734         (JSC::SymbolTable::uniqueIDForVariable):
1735         (JSC::SymbolTable::uniqueIDForOffset):
1736         (JSC::SymbolTable::globalTypeSetForOffset):
1737         (JSC::SymbolTable::globalTypeSetForVariable):
1738         Rename rareData and include a CodeBlock pointer.
1739
1740         (JSC::SymbolTable::rareDataCodeBlock):
1741         (JSC::SymbolTable::setRareDataCodeBlock):
1742         Setter and getter for the rare data. It should only be set once.
1743
1744         (JSC::SymbolTable::visitChildren):
1745         Visit the rare data code block if we have one.
1746
1747         * runtime/JSSymbolTableObject.h:
1748         * runtime/JSSymbolTableObject.cpp:
1749         (JSC::JSSymbolTableObject::deleteProperty):
1750         (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
1751         Give JSSymbolTable its own class info. JSWithScope was unexpectedly
1752         inheriting from JSSymbolTable since it did not have its own and
1753         was using JSScope's class info. Also do a bit of cleanup.
1754
1755         * debugger/DebuggerLocation.cpp: Added.
1756         (JSC::DebuggerLocation::DebuggerLocation):
1757         * debugger/DebuggerLocation.h: Added.
1758         (JSC::DebuggerLocation::DebuggerLocation):
1759         Construction from a ScriptExecutable.
1760
1761         * runtime/JSScope.cpp:
1762         (JSC::JSScope::symbolTable):
1763         * runtime/JSScope.h:
1764         * debugger/DebuggerScope.h:
1765         * debugger/DebuggerScope.cpp:
1766         (JSC::DebuggerScope::name):
1767         (JSC::DebuggerScope::location):
1768         Name and location for a scope. This uses:
1769         JSScope -> SymbolTable -> CodeBlock -> Executable
1770
1771         * inspector/protocol/Debugger.json:
1772         * inspector/InjectedScriptSource.js:
1773         (InjectedScript.CallFrameProxy.prototype._wrapScopeChain):
1774         (InjectedScript.CallFrameProxy._createScopeJson):
1775         * inspector/JSJavaScriptCallFrame.cpp:
1776         (Inspector::valueForScopeType):
1777         (Inspector::valueForScopeLocation):
1778         (Inspector::JSJavaScriptCallFrame::scopeDescriptions):
1779         (Inspector::JSJavaScriptCallFrame::scopeType): Deleted.
1780         * inspector/JSJavaScriptCallFrame.h:
1781         * inspector/JSJavaScriptCallFramePrototype.cpp:
1782         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
1783         (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeDescriptions):
1784         (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeType): Deleted.
1785         Simplify this code to build the objects we will send across the protocol
1786         to descript a Scope.
1787
1788 2016-06-30  Saam Barati  <sbarati@apple.com>
1789
1790         missing exception checks in arrayProtoFuncReverse
1791         https://bugs.webkit.org/show_bug.cgi?id=159319
1792         <rdar://problem/27083696>
1793
1794         Reviewed by Filip Pizlo.
1795
1796         * runtime/ArrayPrototype.cpp:
1797         (JSC::arrayProtoFuncToString):
1798         (JSC::arrayProtoFuncReverse):
1799
1800 2016-06-30  Saam Barati  <sbarati@apple.com>
1801
1802         get_by_id_with_this does not trigger a to_this in caller.
1803         https://bugs.webkit.org/show_bug.cgi?id=159226
1804
1805         Reviewed by Keith Miller.
1806
1807         This is a bug if the caller is in sloppy mode and the callee is in strict
1808         mode. This can't happen with ES6 classes because they're all in strict mode,
1809         but it can happen with method syntax on an object literal. The caller must
1810         to_this on |this| when it knows that it performs super property accesses.
1811
1812         * bytecompiler/BytecodeGenerator.cpp:
1813         (JSC::BytecodeGenerator::BytecodeGenerator):
1814         * tests/stress/super-property-access-object-literal-to-this-2.js: Added.
1815         (assert):
1816         (test):
1817         (let.o1.get foo):
1818         (let.o2.a):
1819         (let.o2.aa):
1820         * tests/stress/super-property-access-object-literal-to-this.js: Added.
1821         (assert):
1822         (test):
1823         (let.o1.get foo):
1824         (let.o2.a):
1825         (let.o2.aa):
1826         (let.o2.b):
1827         (let.o2.bb):
1828         * tests/stress/super-property-access-to-this.js: Added.
1829         (assert):
1830         (test):
1831         (Base.prototype.get foo):
1832         (Base):
1833         (Child.prototype.a):
1834         (Child.prototype.b):
1835         (Child):
1836
1837 2016-06-30  Saam Barati  <sbarati@apple.com>
1838
1839         We need to to_this when an inner arrow function uses 'this'
1840         https://bugs.webkit.org/show_bug.cgi?id=159290
1841         <rdar://problem/27058322>
1842
1843         Reviewed by Geoffrey Garen.
1844
1845         We put the |this| value into the closure object when there
1846         is an arrow function that uses |this|. However, an arrow function
1847         using |this| wasn't causing the creator of the closure that
1848         holds |this| to to_this its value before putting it in the
1849         closure. That's a huge bug because it means some arrow functions
1850         can capture the raw |this| value, which might be a JSLexicalEnvironment.
1851         This patch fixes this by adding an easy to check to see if any
1852         inner arrow functions use |this|, and if any do, it will to_this
1853         the |this| value.
1854
1855         * bytecompiler/BytecodeGenerator.cpp:
1856         (JSC::BytecodeGenerator::BytecodeGenerator):
1857         * tests/stress/to-this-before-arrow-function-closes-over-this-that-starts-as-lexical-environment.js: Added.
1858         (assert):
1859         (obj):
1860         (foo.capture):
1861         (foo.wrapper.let.x.):
1862         (foo2.capture):
1863         (foo2.wrapper.let.x.):
1864         (foo2.wrapper.bar):
1865
1866 2016-06-29  Filip Pizlo  <fpizlo@apple.com>
1867
1868         Generators violate bytecode liveness validation
1869         https://bugs.webkit.org/show_bug.cgi?id=159279
1870
1871         Reviewed by Yusuke Suzuki.
1872         
1873         Fix a liveness bug found by Basic. The problem is that resume's intended liveness rule is:
1874         "live-in is just the token argument", but the liveness analysis thought that the rule was
1875         "live-in is live-out minus defs plus live-at-catch". Clearly these two rules are quite
1876         different. The way this sort of worked before is that we would define the defs of resume
1877         as being equal to our prediction of what the live-outs would be. We did this in the hope
1878         that we would subtract all live-outs. But, this misses the live-at-catch part. So, this
1879         change adds another hack to neutralize live-at-catch.
1880         
1881         This would make a lot more sense if we wrote a new liveness analysis that was just for
1882         generator conversion. It could reuse BytecodeUseDef but otherwise it would be a new thing.
1883         It would be easy to write crazy rules for save/resume in such an analysis, especially if
1884         that analysis rewrote the bytecode. We could then just have an op_yield that is a no-op.
1885         We would just record the live-outs of op_yield and use that for rewriting the code in terms
1886         of a switch statement.
1887
1888         * bytecode/BytecodeLivenessAnalysis.cpp:
1889         (JSC::stepOverInstruction):
1890         (JSC::BytecodeLivenessAnalysis::dumpResults):
1891         * bytecode/CodeBlock.cpp:
1892         (JSC::CodeBlock::dumpBytecode):
1893
1894 2016-06-30  Commit Queue  <commit-queue@webkit.org>
1895
1896         Unreviewed, rolling out r202659.
1897         https://bugs.webkit.org/show_bug.cgi?id=159305
1898
1899         The test for this change times out on mac-wk2 debug and caused
1900         an existing test to crash. (Requested by ryanhaddad on
1901         #webkit).
1902
1903         Reverted changeset:
1904
1905         "Web Inspector: Wrong function name next to scope"
1906         https://bugs.webkit.org/show_bug.cgi?id=158210
1907         http://trac.webkit.org/changeset/202659
1908
1909 2016-06-30  Benjamin Poulain  <bpoulain@apple.com>
1910
1911         [JSC] Date.setYear() misses timeClip()
1912         https://bugs.webkit.org/show_bug.cgi?id=159289
1913
1914         Reviewed by Geoffrey Garen.
1915
1916         * runtime/DatePrototype.cpp:
1917         (JSC::dateProtoFuncSetYear):
1918
1919 2016-06-30  Joseph Pecoraro  <pecoraro@apple.com> and Yusuke Suzuki  <utatane.tea@gmail.com>
1920
1921         [JSC] Implement isFinite / isNaN in JS and make DFG ToNumber accept non number values
1922         https://bugs.webkit.org/show_bug.cgi?id=154022
1923
1924         Reviewed by Filip Pizlo.
1925
1926         We aim at optimizing @toInteger operation.
1927         While it still has an unoptimized part[1], this patch should be a first step.
1928
1929         We introduce the @toNumber builtin intrinsic operation.
1930         This converts the given value to the JS number by emitting op_to_number bytecode.
1931         Previously @toInteger called C++ @Number constructor for that purpose.
1932
1933         And in DFG, op_to_number is converted to DFG ToNumber node.
1934         During DFG, we attempt to convert this to edge filtering and Identity, but if we fail,
1935         we just fall back to calling the C++ function.
1936
1937         To utilize ToNumber in user-land side, we add a path attempting to convert Number constructor calls
1938         to ToNumber DFG nodes. This conversion is useful because `Number(value)` is used to convert a value to a number in JS.
1939
1940         Before this patch, we emit simple edge filtering (NumberUse) instead of emitting DFG node like ToNumber for op_to_number.
1941         But emitting ToNumber is useful, because in the case of `Number(value)`, considering `value` may not be a number is reasonable.
1942
1943         By leveraging @toNumber operation, we rewrite Number.{isFinite, isNaN}, global.{isFinite, isNaN} and @toInteger.
1944
1945         ToNumber DFG node has a value profiling. This profiling is leveraged to determine the result number type of the ToNumber operation.
1946         This value profiling is provided from either NumberConstructor's call operation or op_to_number.
1947
1948         The results (with the added performance tests) show that, while existing cases are performance neutral, the newly added cases gain the performance benefit.
1949         And ASMBench/n-body.c also shows stable ~2% progression.
1950
1951         [1]: https://bugs.webkit.org/show_bug.cgi?id=153738
1952
1953         * CMakeLists.txt:
1954         * DerivedSources.make:
1955         * JavaScriptCore.xcodeproj/project.pbxproj:
1956         * builtins/BuiltinNames.h:
1957         * builtins/GlobalObject.js:
1958         (globalPrivate.isFinite):
1959         (globalPrivate.isNaN):
1960         (globalPrivate.toInteger): Deleted.
1961         (globalPrivate.toLength): Deleted.
1962         (globalPrivate.isDictionary): Deleted.
1963         (globalPrivate.speciesGetter): Deleted.
1964         (globalPrivate.speciesConstructor): Deleted.
1965         * builtins/GlobalOperations.js: Copied from Source/JavaScriptCore/builtins/GlobalObject.js.
1966         (globalPrivate.toInteger):
1967         (globalPrivate.toLength):
1968         (globalPrivate.isDictionary):
1969         (globalPrivate.speciesGetter):
1970         (globalPrivate.speciesConstructor):
1971         * builtins/NumberConstructor.js: Added.
1972         (isFinite):
1973         (isNaN):
1974         * bytecode/BytecodeIntrinsicRegistry.cpp:
1975         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
1976         * bytecode/BytecodeIntrinsicRegistry.h:
1977         * bytecode/BytecodeList.json:
1978         * bytecode/CodeBlock.cpp:
1979         (JSC::CodeBlock::dumpBytecode):
1980         (JSC::CodeBlock::finishCreation):
1981         * bytecompiler/BytecodeGenerator.cpp:
1982         (JSC::BytecodeGenerator::emitUnaryOp):
1983         (JSC::BytecodeGenerator::emitUnaryOpProfiled):
1984         * bytecompiler/BytecodeGenerator.h:
1985         (JSC::BytecodeGenerator::emitToNumber):
1986         * bytecompiler/NodesCodegen.cpp:
1987         (JSC::BytecodeIntrinsicNode::emit_intrinsic_toNumber):
1988         (JSC::UnaryPlusNode::emitBytecode):
1989         * dfg/DFGAbstractInterpreterInlines.h:
1990         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1991         * dfg/DFGBackwardsPropagationPhase.cpp:
1992         (JSC::DFG::BackwardsPropagationPhase::propagate):
1993         * dfg/DFGByteCodeParser.cpp:
1994         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
1995         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
1996         (JSC::DFG::ByteCodeParser::parseBlock):
1997         We use `getPrediction()` to retrieve the heap prediction from the to_number bytecode.
1998         According to the benchmark results, choosing `getPredictionWithoutOSRExit()` causes performance regression (1.5%) in kraken stanford-crypto-aes.
1999
2000         * dfg/DFGClobberize.h:
2001         (JSC::DFG::clobberize):
2002         * dfg/DFGConstantFoldingPhase.cpp:
2003         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2004         * dfg/DFGDoesGC.cpp:
2005         (JSC::DFG::doesGC):
2006         * dfg/DFGFixupPhase.cpp:
2007         (JSC::DFG::FixupPhase::fixupNode):
2008         (JSC::DFG::FixupPhase::fixupToNumber):
2009         * dfg/DFGNode.h:
2010         (JSC::DFG::Node::hasHeapPrediction):
2011         * dfg/DFGNodeType.h:
2012         * dfg/DFGOperations.cpp:
2013         * dfg/DFGOperations.h:
2014         * dfg/DFGPredictionPropagationPhase.cpp:
2015         Always on the heap prediction.
2016
2017         * dfg/DFGSafeToExecute.h:
2018         (JSC::DFG::safeToExecute):
2019         * dfg/DFGSpeculativeJIT32_64.cpp:
2020         (JSC::DFG::SpeculativeJIT::compile):
2021         As of 64bit version, we carefully manage the register reuse. The largest difference between 32bit and 64bit is
2022         `branchIfNotNumber()` requires the temporary register. We should not use the result registers for that since
2023         it may be reuse the argument registers and it can break the argument registers before using them to call the operation.
2024         Currently, we allocate the additional temporary register for that scratch register.
2025
2026         * dfg/DFGSpeculativeJIT64.cpp:
2027         (JSC::DFG::SpeculativeJIT::compile):
2028         Reuse the argument register for the result if possible. And manually decrement the use count in the middle of the node.
2029         This is similar technique used in ToPrimitive. Typically, the child of ToNumber is only used by this ToNumber node since
2030         we would like to perform the type conversion onto this child node here. So this careful register reuse effectively removes
2031         the spills to call the operation. The example of the actually emitted code is the following.
2032
2033         76:<!2:loc11>     ToNumber(Untyped:@68, JS|MustGen|UseAsOther, DoubleimpurenanTopEmpty, R:World, W:Heap, Exits, ClobbersExit, bc#48)  predicting DoubleimpurenanTopEmpty
2034             0x7f986d5fe693: test %rax, %r14
2035             0x7f986d5fe696: jz 0x7f986d5fe6a1
2036             0x7f986d5fe69c: jmp 0x7f986d5fe6d1
2037             0x7f986d5fe6a1: mov %rax, %rsi
2038             0x7f986d5fe6a4: mov %rbp, %rdi
2039             0x7f986d5fe6a7: mov $0x2, 0x24(%rbp)
2040             0x7f986d5fe6ae: mov $0x7f98711ea5f0, %r11
2041             0x7f986d5fe6b8: call *%r11
2042             0x7f986d5fe6bb: mov $0x7f982d3f72d0, %r11
2043             0x7f986d5fe6c5: mov (%r11), %r11
2044             0x7f986d5fe6c8: test %r11, %r11
2045             0x7f986d5fe6cb: jnz 0x7f986d5fe88c
2046
2047         It effectively removes the unnecessary spill to call the operation!
2048
2049         * ftl/FTLCapabilities.cpp:
2050         (JSC::FTL::canCompile):
2051         * ftl/FTLLowerDFGToB3.cpp:
2052         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2053         (JSC::FTL::DFG::LowerDFGToB3::compileToNumber):
2054         (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
2055         * jit/AssemblyHelpers.h:
2056         (JSC::AssemblyHelpers::branchIfNumber):
2057         (JSC::AssemblyHelpers::branchIfNotNumber):
2058         * jit/JITOpcodes.cpp:
2059         (JSC::JIT::emit_op_to_number):
2060         * jit/JITOpcodes32_64.cpp:
2061         (JSC::JIT::emit_op_to_number):
2062         * llint/LowLevelInterpreter32_64.asm:
2063         * llint/LowLevelInterpreter64.asm:
2064         * parser/Nodes.h:
2065         (JSC::UnaryOpNode::opcodeID):
2066         * runtime/CommonSlowPaths.cpp:
2067         (JSC::SLOW_PATH_DECL):
2068         * runtime/JSGlobalObject.cpp:
2069         (JSC::JSGlobalObject::init):
2070         * runtime/JSGlobalObjectFunctions.cpp:
2071         (JSC::globalFuncIsNaN): Deleted.
2072         (JSC::globalFuncIsFinite): Deleted.
2073         * runtime/JSGlobalObjectFunctions.h:
2074         * runtime/MathCommon.h:
2075         (JSC::maxSafeInteger):
2076         (JSC::minSafeInteger):
2077         * runtime/NumberConstructor.cpp:
2078         (JSC::NumberConstructor::finishCreation):
2079         (JSC::numberConstructorFuncIsFinite): Deleted.
2080         (JSC::numberConstructorFuncIsNaN): Deleted.
2081         * runtime/NumberConstructor.h:
2082         * tests/stress/Number-isNaN-basics.js: Added.
2083         (numberIsNaNOnInteger):
2084         (testNumberIsNaNOnIntegers):
2085         (verifyNumberIsNaNOnIntegerWithOtherTypes):
2086         (numberIsNaNOnDouble):
2087         (testNumberIsNaNOnDoubles):
2088         (verifyNumberIsNaNOnDoublesWithOtherTypes):
2089         (numberIsNaNNoArguments):
2090         (numberIsNaNTooManyArguments):
2091         (testNumberIsNaNOnConstants):
2092         (numberIsNaNStructTransition):
2093         (Number.isNaN):
2094         * tests/stress/global-is-finite.js: Added.
2095         (shouldBe):
2096         * tests/stress/global-is-nan.js: Added.
2097         (shouldBe):
2098         * tests/stress/global-isNaN-basics.js: Added.
2099         (isNaNOnInteger):
2100         (testIsNaNOnIntegers):
2101         (verifyIsNaNOnIntegerWithOtherTypes):
2102         (isNaNOnDouble):
2103         (testIsNaNOnDoubles):
2104         (verifyIsNaNOnDoublesWithOtherTypes):
2105         (verifyIsNaNOnCoercedTypes):
2106         (isNaNNoArguments):
2107         (isNaNTooManyArguments):
2108         (testIsNaNOnConstants):
2109         (isNaNTypeCoercionSideEffects):
2110         (i.value.isNaNTypeCoercionSideEffects.valueOf):
2111         (isNaNStructTransition):
2112         (isNaN):
2113         * tests/stress/number-is-finite.js: Added.
2114         (shouldBe):
2115         (test2):
2116         (test3):
2117         * tests/stress/number-is-nan.js: Added.
2118         (shouldBe):
2119         (test2):
2120         (test3):
2121         * tests/stress/to-number-basics.js: Added.
2122         (shouldBe):
2123         * tests/stress/to-number-convert-identity-without-execution.js: Added.
2124         (shouldBe):
2125         (object.valueOf):
2126         (valueOf):
2127         * tests/stress/to-number-int52.js: Added.
2128         (shouldBe):
2129         (object.valueOf):
2130         * tests/stress/to-number-intrinsic-convert-to-identity-without-execution.js: Added.
2131         (shouldBe):
2132         (object.valueOf):
2133         (valueOf):
2134         * tests/stress/to-number-intrinsic-int52.js: Added.
2135         (shouldBe):
2136         (object.valueOf):
2137         * tests/stress/to-number-intrinsic-object-without-execution.js: Added.
2138         (shouldBe):
2139         (object.valueOf):
2140         * tests/stress/to-number-intrinsic-value-profiling.js: Added.
2141         (shouldBe):
2142         (object.valueOf):
2143         * tests/stress/to-number-object-without-execution.js: Added.
2144         (shouldBe):
2145         (object.valueOf):
2146         * tests/stress/to-number-object.js: Added.
2147         (shouldBe):
2148         (test12):
2149         (object1.valueOf):
2150         (test2):
2151         (test22):
2152         (object2.valueOf):
2153         (test3):
2154         (test32):
2155         (object3.valueOf):
2156         * tests/stress/to-number-value-profiling.js: Added.
2157         (shouldBe):
2158         (object.valueOf):
2159
2160 2016-06-29  Benjamin Poulain  <benjamin@webkit.org>
2161
2162         Fix the debug build after r202667
2163
2164         * runtime/JSTypedArrayViewPrototype.cpp:
2165         (JSC::JSTypedArrayViewPrototype::finishCreation):
2166         The putDirect was missing the Accessor flag for the GetterSetter.
2167
2168 2016-06-29  Michael Saboff  <msaboff@apple.com>
2169
2170         REGRESSION(200114): Netflix app does not see ChromeCast
2171         https://bugs.webkit.org/show_bug.cgi?id=159287
2172
2173         Reviewed by Benjamin Poulain.
2174
2175         Change set 200114 changed the behavior of how we check for whether or not we
2176         wrap Objective C init methods in JavaScript constructors.  The prior method
2177         checked the version of JavaScriptCore that was linked with the application.
2178         If the application was not directly linked with JavaScriptCore the prior
2179         method indicated that we shouldn't create constructors.  The new method uses
2180         the SDK the application was compiled with.  Using the new method, an
2181         application compiled with iOS SDK 8.0 or greater would create constructors
2182         and not export init methods to JavaScript.  The problem is that an existing
2183         application that hasn't been recompiled will get a different answer using
2184         the new method.  We need to come up with a method that works in a compatible
2185         way with existing programs, but provides a newly compiled program with the
2186         "is built with SDK N or greater" check.
2187         
2188         Added back the prior check of the version of JavaScriptCore the program was
2189         directly linked against.  However we only use this check if we directly linked
2190         with JavaScriptCore.  Otherwise we fall through to check against the SDK the
2191         program was built with.  Changed the iOS SDK version we check
2192         against to be the new version of iOS, iOS 10.
2193
2194         This provides compatible behavior for existing programs.  It may be the case
2195         that some of those programs may require changes when they are rebuilt with the
2196         iOS 10 SDK or later.
2197
2198         * API/JSWrapperMap.mm:
2199         (supportsInitMethodConstructors):
2200
2201 2016-06-29  Benjamin Poulain  <bpoulain@apple.com>
2202
2203         [JSC] Minor TypedArray fixes
2204         https://bugs.webkit.org/show_bug.cgi?id=159286
2205
2206         Reviewed by Keith Miller.
2207
2208         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
2209         (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
2210         See https://tc39.github.io/ecma262/#sec-%typedarray%
2211
2212         * runtime/JSTypedArrayViewPrototype.cpp:
2213         (JSC::typedArrayViewPrivateFuncLength):
2214         See https://tc39.github.io/ecma262/#sec-get-%typedarray%.prototype.length
2215
2216         (JSC::typedArrayViewProtoGetterFuncToStringTag):
2217         Yep, that's odd.
2218         See https://tc39.github.io/ecma262/#sec-get-%typedarray%.prototype-@@tostringtag
2219
2220         (JSC::JSTypedArrayViewPrototype::finishCreation):
2221         See the last paragraph of https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects
2222
2223 2016-06-29  Joseph Pecoraro  <pecoraro@apple.com>
2224
2225         Web Inspector: API View of Native DOM APIs looks poor (TypeErrors for native getters)
2226         https://bugs.webkit.org/show_bug.cgi?id=158334
2227         <rdar://problem/26615366>
2228
2229         Reviewed by Timothy Hatcher.
2230
2231         * inspector/InjectedScriptSource.js:
2232         (InjectedScript.prototype._getProperties):
2233         (InjectedScript.prototype._propertyDescriptors):
2234         Do not create fake value property descriptors for native accessors
2235         unless requested. This means, getProperties for a native prototype
2236         should return  accessors for native accessors just like it does
2237         for normal non-native accessors (getters/setters).
2238
2239         (InjectedScript.prototype.getProperties):
2240         Do not produce fake value accessors for native accessors.
2241
2242         (InjectedScript.prototype.getDisplayableProperties):
2243         (InjectedScript.RemoteObject.prototype._generatePreview):
2244         Do produce fake value accessors for native accessors.
2245
2246 2016-06-29  Saam barati  <sbarati@apple.com>
2247
2248         JSGlobalLexicalEnvironment needs a toThis implementation
2249         https://bugs.webkit.org/show_bug.cgi?id=159285
2250
2251         Reviewed by Mark Lam.
2252
2253         This was a huge oversight of my original implementation. It gave users
2254         of the language direct access to the JSGlobalLexicalEnvironment object.
2255
2256         * runtime/JSGlobalLexicalEnvironment.cpp:
2257         (JSC::JSGlobalLexicalEnvironment::isConstVariable):
2258         (JSC::JSGlobalLexicalEnvironment::toThis):
2259         * runtime/JSGlobalLexicalEnvironment.h:
2260         (JSC::JSGlobalLexicalEnvironment::isEmpty):
2261         * tests/stress/global-lexical-environment-to-this.js: Added.
2262         (assert):
2263         (let.f):
2264         (let.fStrict):
2265
2266 2016-06-29  Joseph Pecoraro  <pecoraro@apple.com>
2267
2268         Web Inspector: Wrong function name next to scope
2269         https://bugs.webkit.org/show_bug.cgi?id=158210
2270         <rdar://problem/26543093>
2271
2272         Reviewed by Brian Burg.
2273
2274         * CMakeLists.txt:
2275         * JavaScriptCore.xcodeproj/project.pbxproj:
2276         Add DebuggerLocation. A helper for describing a unique location.
2277
2278         * bytecode/CodeBlock.cpp:
2279         (JSC::CodeBlock::setConstantRegisters):
2280         When compiled with debug info, add a SymbolTable rare data pointer
2281         back to the CodeBlock. This will be used later to get JSScope debug
2282         info if Web Inspector pauses.
2283
2284         * runtime/SymbolTable.h:
2285         * runtime/SymbolTable.cpp:
2286         (JSC::SymbolTable::cloneScopePart):
2287         (JSC::SymbolTable::prepareForTypeProfiling):
2288         (JSC::SymbolTable::uniqueIDForVariable):
2289         (JSC::SymbolTable::uniqueIDForOffset):
2290         (JSC::SymbolTable::globalTypeSetForOffset):
2291         (JSC::SymbolTable::globalTypeSetForVariable):
2292         Rename rareData and include a CodeBlock pointer.
2293
2294         (JSC::SymbolTable::rareDataCodeBlock):
2295         (JSC::SymbolTable::setRareDataCodeBlock):
2296         Setter and getter for the rare data. It should only be set once.
2297
2298         (JSC::SymbolTable::visitChildren):
2299         Visit the rare data code block if we have one.
2300
2301         * debugger/DebuggerLocation.cpp: Added.
2302         (JSC::DebuggerLocation::DebuggerLocation):
2303         * debugger/DebuggerLocation.h: Added.
2304         (JSC::DebuggerLocation::DebuggerLocation):
2305         Construction from a ScriptExecutable.
2306
2307         * runtime/JSScope.cpp:
2308         (JSC::JSScope::symbolTable):
2309         * runtime/JSScope.h:
2310         * debugger/DebuggerScope.h:
2311         * debugger/DebuggerScope.cpp:
2312         (JSC::DebuggerScope::name):
2313         (JSC::DebuggerScope::location):
2314         Name and location for a scope. This uses:
2315         JSScope -> SymbolTable -> CodeBlock -> Executable
2316
2317         * inspector/protocol/Debugger.json:
2318         * inspector/InjectedScriptSource.js:
2319         (InjectedScript.CallFrameProxy.prototype._wrapScopeChain):
2320         (InjectedScript.CallFrameProxy._createScopeJson):
2321         * inspector/JSJavaScriptCallFrame.cpp:
2322         (Inspector::valueForScopeType):
2323         (Inspector::valueForScopeLocation):
2324         (Inspector::JSJavaScriptCallFrame::scopeDescriptions):
2325         (Inspector::JSJavaScriptCallFrame::scopeType): Deleted.
2326         * inspector/JSJavaScriptCallFrame.h:
2327         * inspector/JSJavaScriptCallFramePrototype.cpp:
2328         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
2329         (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeDescriptions):
2330         (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeType): Deleted.
2331         Simplify this code to build the objects we will send across the protocol
2332         to descript a Scope.
2333
2334 2016-06-29  Saam barati  <sbarati@apple.com>
2335
2336         We don't emit TDZ checks for call_eval
2337         https://bugs.webkit.org/show_bug.cgi?id=159277
2338         <rdar://problem/27018801>
2339
2340         Reviewed by Benjamin Poulain.
2341
2342         This is a problem if you're trying to call a TDZ variable
2343         that is named 'eval'.
2344
2345         * bytecompiler/NodesCodegen.cpp:
2346         (JSC::EvalFunctionCallNode::emitBytecode):
2347         * tests/stress/variable-named-eval-under-tdz.js: Added.
2348         (shouldThrowTDZ):
2349         (test):
2350         (test.foo):
2351         (throw.new.Error):
2352
2353 2016-06-29  Mark Lam  <mark.lam@apple.com>
2354
2355         Add support for collecting cumulative LLINT stats via a JSC_llintStatsFile option.
2356         https://bugs.webkit.org/show_bug.cgi?id=159274
2357
2358         Reviewed by Keith Miller.
2359
2360         * jsc.cpp:
2361         (main):
2362         * llint/LLIntData.cpp:
2363         (JSC::LLInt::initialize):
2364         (JSC::LLInt::Data::finalizeStats):
2365         (JSC::LLInt::compareStats):
2366         (JSC::LLInt::Data::dumpStats):
2367         (JSC::LLInt::Data::ensureStats):
2368         (JSC::LLInt::Data::loadStats):
2369         (JSC::LLInt::Data::resetStats):
2370         (JSC::LLInt::Data::saveStats):
2371         * llint/LLIntData.h:
2372         (JSC::LLInt::Data::opcodeStats):
2373         * runtime/Options.cpp:
2374         (JSC::Options::isAvailable):
2375         (JSC::recomputeDependentOptions):
2376         (JSC::Options::initialize):
2377         * runtime/Options.h:
2378
2379 2016-06-29  Saam barati  <sbarati@apple.com>
2380
2381         Destructuring variable declaration is missing a validation of the syntax of a sub production when there is a rhs
2382         https://bugs.webkit.org/show_bug.cgi?id=159267
2383
2384         Reviewed by Mark Lam.
2385
2386         We were parsing something without checking if it had a syntax error.
2387         This is wrong for many reasons, but it could actually cause a crash
2388         in a debug build if you parsed particular programs.
2389
2390         * parser/Parser.cpp:
2391         (JSC::Parser<LexerType>::parseVariableDeclarationList):
2392
2393 2016-06-29  Joseph Pecoraro  <pecoraro@apple.com>
2394
2395         Web Inspector: Show Shadow Root type in DOM Tree
2396         https://bugs.webkit.org/show_bug.cgi?id=159236
2397         <rdar://problem/27068521>
2398
2399         Reviewed by Timothy Hatcher.
2400
2401         * inspector/protocol/DOM.json:
2402         Include optional shadowRootType property for DOMNodes.
2403
2404 2016-06-29  Commit Queue  <commit-queue@webkit.org>
2405
2406         Unreviewed, rolling out r202627.
2407         https://bugs.webkit.org/show_bug.cgi?id=159266
2408
2409         patch is broken on arm (Requested by keith_miller on #webkit).
2410
2411         Reverted changeset:
2412
2413         "LLInt should support other types of prototype GetById
2414         caching."
2415         https://bugs.webkit.org/show_bug.cgi?id=158083
2416         http://trac.webkit.org/changeset/202627
2417
2418 2016-06-29  Benjamin Poulain  <bpoulain@apple.com>
2419
2420         [JSC] Fix small issues of TypedArray prototype
2421         https://bugs.webkit.org/show_bug.cgi?id=159248
2422
2423         Reviewed by Saam Barati.
2424
2425         First, TypedArray's toString and Array's toString
2426         should be the same function.
2427         I moved the function to GlobalObject and each array type
2428         gets it as needed.
2429
2430         Then TypedArray length was supposed to be configurable.
2431         I removed the "DontDelete" flag accordingly.
2432
2433         * runtime/ArrayPrototype.cpp:
2434         (JSC::ArrayPrototype::finishCreation):
2435         * runtime/JSGlobalObject.cpp:
2436         (JSC::JSGlobalObject::init):
2437         (JSC::JSGlobalObject::visitChildren):
2438         * runtime/JSGlobalObject.h:
2439         (JSC::JSGlobalObject::arrayProtoToStringFunction):
2440         * runtime/JSTypedArrayViewPrototype.cpp:
2441         (JSC::JSTypedArrayViewPrototype::finishCreation):
2442
2443 2016-06-29  Caio Lima  <ticaiolima@gmail.com>
2444
2445         LLInt should support other types of prototype GetById caching.
2446         https://bugs.webkit.org/show_bug.cgi?id=158083
2447
2448         Recently, we started supporting prototype load caching for get_by_id
2449         in the LLInt. This patch is expading the caching strategy to enable
2450         cache the prototype accessor and custom acessors.
2451
2452         Similarly to the get_by_id_proto_load bytecode, we are adding new
2453         bytecodes called get_by_id_proto_accessor that uses the calculated
2454         offset of a object to call a getter function and get_by_id_proto_custom
2455         that stores the pointer to the custom function and call them directly
2456         from LowLevelInterpreter.
2457
2458         Reviewed by Keith Miller
2459
2460         * bytecode/BytecodeList.json:
2461         * bytecode/BytecodeUseDef.h:
2462         (JSC::computeUsesForBytecodeOffset):
2463         (JSC::computeDefsForBytecodeOffset):
2464         * bytecode/CodeBlock.cpp:
2465         (JSC::CodeBlock::printGetByIdOp):
2466         (JSC::CodeBlock::dumpBytecode):
2467         (JSC::CodeBlock::finalizeLLIntInlineCaches):
2468         * bytecode/GetByIdStatus.cpp:
2469         (JSC::GetByIdStatus::computeFromLLInt):
2470         * dfg/DFGByteCodeParser.cpp:
2471         (JSC::DFG::ByteCodeParser::parseBlock):
2472         * dfg/DFGCapabilities.cpp:
2473         (JSC::DFG::capabilityLevel):
2474         * jit/JIT.cpp:
2475         (JSC::JIT::privateCompileMainPass):
2476         (JSC::JIT::privateCompileSlowCases):
2477         * llint/LLIntSlowPaths.cpp:
2478         (JSC::LLInt::setupGetByIdPrototypeCache):
2479         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2480         * llint/LLIntSlowPaths.h:
2481         * llint/LowLevelInterpreter32_64.asm:
2482         * llint/LowLevelInterpreter64.asm:
2483
2484 2016-06-28  Commit Queue  <commit-queue@webkit.org>
2485
2486         Unreviewed, rolling out r202580.
2487         https://bugs.webkit.org/show_bug.cgi?id=159245
2488
2489         Caused all WKTR tests to fail on GuardMalloc and Production
2490         only for unknown reasons, investigating offline. (Requested by
2491         brrian on #webkit).
2492
2493         Reverted changeset:
2494
2495         "RunLoop::Timer should use constructor templates instead of
2496         class templates"
2497         https://bugs.webkit.org/show_bug.cgi?id=159153
2498         http://trac.webkit.org/changeset/202580
2499
2500 2016-06-28  Keith Miller  <keith_miller@apple.com>
2501
2502         We should not crash there is a finally inside a for-in loop
2503         https://bugs.webkit.org/show_bug.cgi?id=159243
2504         <rdar://problem/27018910>
2505
2506         Reviewed by Benjamin Poulain.
2507
2508         Previously we would swap the m_forInContext with an empty vector
2509         then attempt to shrink the size of m_forInContext by the amount
2510         we expected. This meant that if there was more than one ForInContext
2511         on the stack and we wanted to pop exactly one off we would crash.
2512         This patch makes ForInContexts RefCounted so they can be duplicated
2513         into other vectors. It also has ForInContexts copy the entire stack
2514         rather than do the swap that we did before. This makes ForInContexts
2515         work the same as the other contexts.
2516
2517         * bytecompiler/BytecodeGenerator.cpp:
2518         (JSC::BytecodeGenerator::emitComplexPopScopes):
2519         (JSC::BytecodeGenerator::pushIndexedForInScope):
2520         (JSC::BytecodeGenerator::pushStructureForInScope):
2521         * bytecompiler/BytecodeGenerator.h:
2522         * tests/stress/finally-for-in.js: Added.
2523         (repeat):
2524         (createSimple):
2525
2526 2016-06-28  Saam Barati  <sbarati@apple.com>
2527
2528         Assertion failure or crash when accessing let-variable in TDZ with eval with a function in it that returns let variable
2529         https://bugs.webkit.org/show_bug.cgi?id=158796
2530         <rdar://problem/26984659>
2531
2532         Reviewed by Michael Saboff.
2533
2534         There was a bug where some functions inside of an eval were
2535         omitting a necessary TDZ check. This obviously leads to bad
2536         things because a variable under TDZ is the null pointer.
2537         The eval's bytecode was generated with the correct TDZ set, but 
2538         it created all its functions before pushing that TDZ set onto
2539         the stack. That's a mistake. Those functions need to be created with
2540         that TDZ set. The solution is simple, the TDZ set that the eval
2541         is created with needs to be pushed onto the TDZ stack before
2542         the eval creates any functions.
2543
2544         * bytecompiler/BytecodeGenerator.cpp:
2545         (JSC::BytecodeGenerator::BytecodeGenerator):
2546         * tests/stress/variable-under-tdz-eval-tricky.js: Added.
2547         (assert):
2548         (throw.new.Error):
2549         (assert.try.underTDZ):
2550
2551 2016-06-28  Michael Saboff  <msaboff@apple.com>
2552
2553         REGRESSION (r200946): Improper backtracking from last alternative in sticky patterns
2554         https://bugs.webkit.org/show_bug.cgi?id=159233
2555
2556         Reviewed by Mark Lam.
2557
2558         Jump to fail exit code when the last alternative of a sticky pattern fails.
2559
2560         * yarr/YarrJIT.cpp:
2561         (JSC::Yarr::YarrGenerator::backtrack):
2562
2563 2016-06-28  Saam Barati  <sbarati@apple.com>
2564
2565         some Watchpoints' ::fireInternal method will call operations that might GC where the GC will cause the watchpoint itself to destruct
2566         https://bugs.webkit.org/show_bug.cgi?id=159198
2567         <rdar://problem/26302360>
2568
2569         Reviewed by Filip Pizlo.
2570
2571         Firing a watchpoint may cause a GC to happen. This GC could destroy various
2572         Watchpoints themselves while they're in the process of firing. It's not safe
2573         for most Watchpoints to be destructed while they're in the middle of firing.
2574         This GC could also destroy the WatchpointSet itself, and it's not in a safe
2575         state to be destroyed. WatchpointSet::fireAllWatchpoints now defers gc for a
2576         while. This prevents a GC from destructing any Watchpoints while they're
2577         in the process of firing. This bug was being hit by the stress GC bots
2578         because we would destruct a particular Watchpoint while it was firing,
2579         and then we would access its field after it had already been destroyed.
2580         This was causing all kinds of weird symptoms. Also, this was easier to
2581         catch when running with guard malloc because the first access after
2582         destruction would lead to a crash.
2583
2584         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
2585         (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
2586         * bytecode/CodeBlock.cpp:
2587         (JSC::CodeBlock::finishCreation):
2588         * bytecode/VariableWriteFireDetail.cpp:
2589         (JSC::VariableWriteFireDetail::dump):
2590         (JSC::VariableWriteFireDetail::touch):
2591         * bytecode/VariableWriteFireDetail.h:
2592         * bytecode/Watchpoint.cpp:
2593         (JSC::WatchpointSet::add):
2594         (JSC::WatchpointSet::fireAllSlow):
2595         (JSC::WatchpointSet::fireAllWatchpoints):
2596         (JSC::InlineWatchpointSet::add):
2597         (JSC::InlineWatchpointSet::fireAll):
2598         (JSC::InlineWatchpointSet::inflateSlow):
2599         * bytecode/Watchpoint.h:
2600         (JSC::WatchpointSet::startWatching):
2601         (JSC::WatchpointSet::fireAll):
2602         (JSC::WatchpointSet::touch):
2603         (JSC::WatchpointSet::invalidate):
2604         (JSC::WatchpointSet::isBeingWatched):
2605         (JSC::WatchpointSet::offsetOfState):
2606         (JSC::WatchpointSet::addressOfSetIsNotEmpty):
2607         (JSC::InlineWatchpointSet::startWatching):
2608         (JSC::InlineWatchpointSet::fireAll):
2609         (JSC::InlineWatchpointSet::invalidate):
2610         (JSC::InlineWatchpointSet::touch):
2611         * bytecompiler/BytecodeGenerator.cpp:
2612         (JSC::BytecodeGenerator::BytecodeGenerator):
2613         * dfg/DFGOperations.cpp:
2614         * interpreter/Interpreter.cpp:
2615         (JSC::Interpreter::execute):
2616         * jit/JITOperations.cpp:
2617         * jsc.cpp:
2618         (WTF::Masquerader::create):
2619         * llint/LLIntSlowPaths.cpp:
2620         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2621         * runtime/ArrayBufferNeuteringWatchpoint.cpp:
2622         (JSC::ArrayBufferNeuteringWatchpoint::fireAll):
2623         * runtime/FunctionRareData.cpp:
2624         (JSC::FunctionRareData::clear):
2625         * runtime/InferredType.cpp:
2626         (JSC::InferredType::willStoreValueSlow):
2627         (JSC::InferredType::makeTopSlow):
2628         (JSC::InferredType::set):
2629         (JSC::InferredType::removeStructure):
2630         (JSC::InferredType::InferredStructureWatchpoint::fireInternal):
2631         * runtime/InferredValue.cpp:
2632         (JSC::InferredValue::notifyWriteSlow):
2633         (JSC::InferredValue::ValueCleanup::finalizeUnconditionally):
2634         * runtime/InferredValue.h:
2635         (JSC::InferredValue::notifyWrite):
2636         (JSC::InferredValue::invalidate):
2637         * runtime/JSGlobalObject.cpp:
2638         (JSC::JSGlobalObject::haveABadTime):
2639         * runtime/JSSymbolTableObject.h:
2640         (JSC::symbolTablePutTouchWatchpointSet):
2641         (JSC::symbolTablePutInvalidateWatchpointSet):
2642         * runtime/Structure.cpp:
2643         (JSC::Structure::didCachePropertyReplacement):
2644         (JSC::Structure::startWatchingInternalProperties):
2645         (JSC::DeferredStructureTransitionWatchpointFire::~DeferredStructureTransitionWatchpointFire):
2646         (JSC::DeferredStructureTransitionWatchpointFire::add):
2647         (JSC::Structure::didTransitionFromThisStructure):
2648         (JSC::Structure::prototypeForLookup):
2649         * runtime/StructureInlines.h:
2650         (JSC::Structure::didReplaceProperty):
2651         (JSC::Structure::propertyReplacementWatchpointSet):
2652         * runtime/SymbolTable.h:
2653         (JSC::SymbolTableEntry::isDontEnum):
2654         (JSC::SymbolTableEntry::disableWatching):
2655         * runtime/VM.cpp:
2656         (JSC::VM::addImpureProperty):
2657         (JSC::enableProfilerWithRespectToCount):
2658
2659 2016-06-28  Filip Pizlo  <fpizlo@apple.com>
2660
2661         JSRopeString should use release asserts, not debug asserts, about substring bounds
2662         https://bugs.webkit.org/show_bug.cgi?id=159227
2663
2664         Reviewed by Saam Barati.
2665         
2666         According to my experiments this change costs nothing.  That's not surprising since the
2667         most common way to construct a rope these days is inlined into the JIT, which does its own
2668         safety checks.  This makes us crash sooner rather than corrupting memory.
2669
2670         * runtime/JSString.h:
2671
2672 2016-06-28  Brian Burg  <bburg@apple.com>
2673
2674         RunLoop::Timer should use constructor templates instead of class templates
2675         https://bugs.webkit.org/show_bug.cgi?id=159153
2676
2677         Reviewed by Alex Christensen.
2678
2679         Remove the RunLoop::Timer class template argument, and pass its constructor
2680         a reference to `this` instead of a pointer to `this`.
2681
2682         * inspector/agents/InspectorHeapAgent.cpp:
2683         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
2684
2685 2016-06-28  Joseph Pecoraro  <pecoraro@apple.com>
2686
2687         Web Inspector: selectElement.options shows unexpected entries in console (named indexes beyond collection length)
2688         https://bugs.webkit.org/show_bug.cgi?id=159192
2689
2690         Reviewed by Timothy Hatcher.
2691
2692         * inspector/InjectedScriptSource.js:
2693         (InjectedScript.prototype.arrayIndexPropertyNames):
2694         Start with an empty array because we just push valid indexes.
2695
2696         (InjectedScript.prototype._propertyDescriptors):
2697         Avoid the >100 length requirement, and always treat the
2698         array-like objects the same. The frontend currently
2699         doesn't show named indexes for arrays anyways, so they
2700         would have been unused.
2701
2702 2016-06-28  Per Arne Vollan  <pvollan@apple.com>
2703
2704         [Win] Skip failing INTL test.
2705         https://bugs.webkit.org/show_bug.cgi?id=159141
2706
2707         Reviewed by Brent Fulgham.
2708
2709         INTL is not enabled on Windows.
2710
2711         * tests/stress/intl-constructors-with-proxy.js:
2712         (shouldBe):
2713
2714 2016-06-28  Joonghun Park  <jh718.park@samsung.com>
2715
2716         [JSC] Fix build break since r202502 - 2
2717         https://bugs.webkit.org/show_bug.cgi?id=159194
2718
2719         Reviewed by Gyuyoung Kim.
2720
2721         Fix about the error message below.
2722         error: control reaches end of non-void function [-Werror=return-type]
2723
2724         * b3/B3TypeMap.h: add #pragma GCC diagnostic ignored "-Wreturn-type".
2725
2726 2016-06-28  Joonghun Park  <jh718.park@samsung.com>
2727
2728         [JSC] Fix build break since r202502
2729         https://bugs.webkit.org/show_bug.cgi?id=159194
2730
2731         Reviewed by Alex Christensen.
2732
2733         Fix about the error message below.
2734         error: control reaches end of non-void function [-Werror=return-type]
2735
2736         * b3/B3TypeMap.h:
2737         (JSC::B3::TypeMap::at): add missing ASSERT_NOT_REACHED().
2738
2739 2016-06-27  Keith Miller  <keith_miller@apple.com>
2740
2741         Fix bad assert in StructureRareData::setObjectToStringValue
2742         https://bugs.webkit.org/show_bug.cgi?id=159171
2743         <rdar://problem/26987355>
2744
2745         Reviewed by Mark Lam.
2746
2747         We should not have expected the generateConditionsForPrototypePropertyHit would succeed.
2748         There are many reasons it might fail including that there is a proxy somewhere on the
2749         prototype chain of the object.
2750
2751         * runtime/StructureRareData.cpp:
2752         (JSC::StructureRareData::setObjectToStringValue):
2753         * tests/stress/object-toString-with-proxy.js: Added.
2754         (get target):
2755
2756 2016-06-27  Filip Pizlo  <fpizlo@apple.com>
2757
2758         Crashing at an unreachable code trap in FTL should give more information
2759         https://bugs.webkit.org/show_bug.cgi?id=159177
2760
2761         Reviewed by Saam Barati.
2762         
2763         This stuffs information into registers so that we have some chance of seeing what happened
2764         by looking at the register dumps.
2765
2766         * assembler/AbortReason.h:
2767         * ftl/FTLLowerDFGToB3.cpp:
2768         (JSC::FTL::DFG::ftlUnreachable):
2769         (JSC::FTL::DFG::LowerDFGToB3::compileBlock):
2770         (JSC::FTL::DFG::LowerDFGToB3::crash):
2771
2772 2016-06-27  Filip Pizlo  <fpizlo@apple.com>
2773
2774         Clean up resetting reachability in B3/Air
2775         https://bugs.webkit.org/show_bug.cgi?id=159170
2776
2777         Reviewed by Geoffrey Garen.
2778         
2779         When I fixed bug 159165, I took the brute force approach. I still used the
2780         B3::resetReachability() method, and changed the callback to record the set of deleted values
2781         instead of deleting them eagerly. But this means tracking the set of deleted values, even
2782         though resetReachability() already internally tracks the set of deleted blocks. You can find
2783         out if a value is deleted by asking if its owning block was deleted.
2784         
2785         So, this change refactors B3::resetReachability() into a new helper called
2786         B3::recomputePredecessors(). This new helper skips the block deletion step, and lets the
2787         client delete blocks. This lets Air delete blocks the same way that it did before, and it
2788         lets B3 use the isBlockDead() method (which is a glorified proxy for
2789         block->predecessors().isEmpty()) to track which values are deleted. This allows B3 to turn
2790         Upsilons that point to dead Phis into Nops before deleting the blocks.
2791         
2792         This shouldn't affect performance or anything real. It just makes the code cleaner.
2793
2794         * b3/B3BasicBlockUtils.h:
2795         (JSC::B3::updatePredecessorsAfter):
2796         (JSC::B3::recomputePredecessors):
2797         (JSC::B3::isBlockDead):
2798         (JSC::B3::resetReachability): Deleted.
2799         * b3/B3Procedure.cpp:
2800         (JSC::B3::Procedure::resetReachability):
2801         (JSC::B3::Procedure::invalidateCFG):
2802         * b3/air/AirCode.cpp:
2803         (JSC::B3::Air::Code::resetReachability):
2804         (JSC::B3::Air::Code::dump):
2805
2806 2016-06-27  Brian Burg  <bburg@apple.com>
2807
2808         Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
2809         https://bugs.webkit.org/show_bug.cgi?id=159075
2810         <rdar://problem/26094341>
2811
2812         Reviewed by Filip Pizlo.
2813
2814         This change caused JSC stress tests to all hit an assertion in RunLoop.
2815         We should use RunLoop::current() to create the RunLoop::Timer since JSC-only
2816         clients like testapi and jsc don't ever call initializeMainRunLoop().
2817
2818         * inspector/agents/InspectorHeapAgent.cpp:
2819         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
2820
2821 2016-06-27  Filip Pizlo  <fpizlo@apple.com>
2822
2823         B3::Procedure::resetReachability() can create dangling references from Upsilons to Phis
2824         https://bugs.webkit.org/show_bug.cgi?id=159165
2825
2826         Reviewed by Mark Lam.
2827         
2828         You can delete an unreachable block that has a Phi but some prior block may still have an
2829         Upsilon pointing to that Phi. This can happen if the Upsilon precedes a Check that always
2830         exits or it can happen if we remove some successor of a block and this block had an Upsilon
2831         for one of the removed successors. These things are valid IR even if they are not canonical.
2832         Our policy for not-canonical-but-valid IR is that the compiler should still emit valid code
2833         in the end.
2834         
2835         The solution is to have Procedure::resetReachability() turn those Upsilons into Nops.
2836
2837         * b3/B3Procedure.cpp:
2838         (JSC::B3::Procedure::resetReachability): Fix the bug.
2839         * b3/B3Validate.h:
2840         * b3/testb3.cpp:
2841         (JSC::B3::testResetReachabilityDanglingReference): Add a test. This always crashes prior to this change.
2842         * dfg/DFGGraph.cpp:
2843         (JSC::DFG::Graph::killUnreachableBlocks): Add a FIXME about a possible similar bug.
2844
2845 2016-06-27  Keith Miller  <keith_miller@apple.com>
2846
2847         Add comment to Module feature in features.json
2848         https://bugs.webkit.org/show_bug.cgi?id=159159
2849
2850         Reviewed by Saam Barati.
2851
2852         * features.json:
2853
2854 2016-06-27  Keith Miller  <keith_miller@apple.com>
2855
2856         Update features.json for ES6 completed features.
2857         https://bugs.webkit.org/show_bug.cgi?id=159152
2858
2859         Reviewed by Mark Lam.
2860
2861         * features.json:
2862
2863 2016-06-25  Filip Pizlo  <fpizlo@apple.com>
2864
2865         B3 should not use Nops when deleting unreachable code
2866         https://bugs.webkit.org/show_bug.cgi?id=159120
2867         rdar://problem/26500743
2868
2869         Reviewed by Michael Saboff.
2870         
2871         Prior to this change, transformations that obviated the need for some value could choose
2872         from these ways to kill it:
2873         
2874         - replaceWithIdentity() if we're replacing with another value.
2875         - replaceWithNop() if the type is Void or if we know that we'll fix any users of this
2876           value.
2877         - deleteValue() if the code is unreachable.
2878         
2879         The bug here is that reduceStrength() was being clever about how to get rid of a value.
2880         reduceStrength() may find a Check that must always exit. The goal is to remove any code
2881         dominated by the Check. But it would be awkward to eagerly delete all of the blocks
2882         dominated by this one. So this code took a much simpler approach: it would
2883         replaceWithNop() for all of the values in this block after the Check and it would replace
2884         the terminal with Oops.
2885         
2886         But this corrupts the IR in a subtle way: some of those values may have been non-Void but
2887         now they are Nops so they are Void. reduceStrength() will not yet realize that the blocks
2888         dominated by the one with the Check are unreachable, so it will run all sorts of
2889         optimizations on those blocks. This could have probably manifested as many different kinds
2890         of badness, but the way I found out about this issue was through a crash in
2891         IntRange::top(Type) when inlined into ReduceStrength::rangeFor(). We'd die in a switch
2892         statement over a child's type.
2893         
2894         We could fix this by making rangeFor() tolerate Void. But I think that this would be
2895         dangerous. There could easily be other places in reduceStrength() that assume that value's
2896         children are non-Void. So, this change fixes the Check optimization and adds mechanisms to
2897         prevent other optimizations from breaking the children-are-not-Void rule.
2898         
2899         This introduces two high-level changes:
2900         
2901         - It's no longer legal to replaceWithNop() if the value is not Void. This change alone
2902           would cause reduceStrength() to instacrash in its Check optimization. Almost all other
2903           uses of replaceWithNop() were already following this rule, so they were fine. One other
2904           place was using replaceWithNop() on non-Void values after arranging for them to no
2905           longer have any parents. That was changed to call replaceWithNopIgnoringType(), which
2906           doesn't have any type assertions.
2907         
2908         - For reduceStrength() there is a new Value::replaceWithBottom() method that works with
2909           Void or non-Void and behaves like you would want replaceWithNop() to behave: if you know
2910           that the code is unreachable then it produces something that is guaranteed to be deleted
2911           by later optimizations, and if it's not unreachable, then it's guaranteed to be compiled
2912           to something harmless and cheap. This means replacing the value with an identity that
2913           points to a bottom constant (the 0 for whatever type we have), or just replacing it with
2914           Nop if it's Void.
2915         
2916         This also adds a test case for the reason why we do this: we may have two blocks, where
2917         the first block unconditionally exits while dominating the second block. The second block
2918         references values in the part of the first block that is unreachable. In trunk, this test
2919         would assert in ReduceStrength::rangeFor() because the CheckAdd in the second block would
2920         reference a Nop in the first block.
2921         
2922         This fixes a high volume crash in ReduceStrength::rangeFor(). This crash was very
2923         confusing. Even though we were crashing at a RELEASE_ASSERT_NOT_REACHED() in a switch
2924         statement in IntRange::top(Type), clang was merging that trap with the trap it used for
2925         Vector OOB. The top of the stack in crash dumps looked like:
2926         
2927             JSC::B3::(anonymous namespace)::ReduceStrength::rangeFor(JSC::B3::Value*, unsigned int) + 4477 (Vector.h:655)
2928         
2929         Where Vector.h:655 is:
2930         
2931             OverflowHandler::overflowed();
2932
2933         But this crash was not at Vector.h:655. It was at B3ReduceStrength.cpp:121. The two lines
2934         are both traps, so they got merged despite differences in debug info. This bug would have
2935         been so much easier to fix if I had the right line number.
2936
2937         * b3/B3BottomProvider.h: Added. This is a utility for creating bottom values.
2938         (JSC::B3::BottomProvider::BottomProvider):
2939         (JSC::B3::BottomProvider::operator()):
2940         * b3/B3InsertionSet.cpp: Optimized adding bottom values a bit. We will no longer create pointless duplicates.
2941         (JSC::B3::InsertionSet::insertBottom):
2942         (JSC::B3::InsertionSet::execute):
2943         (JSC::B3::InsertionSet::bottomForType):
2944         * b3/B3InsertionSet.h:
2945         * b3/B3MoveConstants.cpp: Use replaceWithNopIgnoringType() because we *know* that we can replaceWithNop even for non-Void.
2946         * b3/B3Procedure.h:
2947         * b3/B3ReduceStrength.cpp: Use replaceWithBottom().
2948         * b3/B3ReduceStrength.h:
2949         * b3/B3TypeMap.h: I figured if I wrote type-casing code like this once then I'd never want to write it again.
2950         * b3/B3Value.cpp:
2951         (JSC::B3::Value::replaceWithIdentity):
2952         (JSC::B3::Value::replaceWithNop):
2953         (JSC::B3::Value::replaceWithNopIgnoringType):
2954         * b3/B3Value.h:
2955         * b3/B3ValueInlines.h:
2956         (JSC::B3::Value::replaceWithBottom): This is the new method of killing unreachable code.
2957         (JSC::B3::Value::as):
2958         * b3/testb3.cpp: Add new tests!
2959         (JSC::B3::testLateRegister):
2960         (JSC::B3::testReduceStrengthCheckBottomUseInAnotherBlock):
2961         (JSC::B3::zero):
2962         (JSC::B3::run):
2963
2964 2016-06-27  Joseph Pecoraro  <pecoraro@apple.com>
2965
2966         REGRESSION: Web Inspector: Text search broken in resources with <CR>
2967         https://bugs.webkit.org/show_bug.cgi?id=159110
2968         <rdar://problem/27008485>
2969
2970         Reviewed by Brian Burg.
2971
2972         * inspector/ContentSearchUtilities.cpp:
2973         (Inspector::ContentSearchUtilities::lineEndings):
2974         The frontend moved to only treated newlines as line endings in
2975         the TextEditor. The backend however was looking for many
2976         different types of line endings (\r\n, \r, \n). This caused
2977         the line endings to ultimately differ between the frontend
2978         and the backend, so the frontend couldn't find the lines that
2979         the backend was claiming search results were on. Change the
2980         backend to only look for \n line endings.
2981
2982 2016-06-27  Brian Burg  <bburg@apple.com>
2983
2984         Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
2985         https://bugs.webkit.org/show_bug.cgi?id=159075
2986         <rdar://problem/26094341>
2987
2988         Reviewed by Timothy Hatcher.
2989
2990         Move the asynchronous work to a task class that can be cancelled when the
2991         heap agent is reset, disabled or destroyed.
2992
2993         * inspector/agents/InspectorHeapAgent.cpp:
2994         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
2995         (Inspector::SendGarbageCollectionEventsTask::addGarbageCollection):
2996         (Inspector::SendGarbageCollectionEventsTask::reset):
2997         (Inspector::SendGarbageCollectionEventsTask::timerFired):
2998         Added. This holds onto GarbageCollectionData that needs to be sent asynchronously.
2999         It uses the RunLoop variant of Timer and can queue multiple collections to be sent.
3000         The data vector is guarded with a lock so that garbageCollected() can safely add
3001         collection data from a non-main thread while the main thread sends out events.
3002
3003         (Inspector::InspectorHeapAgent::InspectorHeapAgent):
3004         (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
3005         (Inspector::InspectorHeapAgent::disable):
3006         Reset the task when disabling or tearing down the agent so the timer doesn't fire after destruction.
3007
3008         (Inspector::InspectorHeapAgent::didGarbageCollect):
3009         Add the collection data to the task, which will dispatch an event for it asynchronously.
3010
3011         * inspector/agents/InspectorHeapAgent.h:
3012
3013 2016-06-27  Michael Saboff  <msaboff@apple.com>
3014
3015         ES6 Change: Unify handling of RegExp CharacterClassEscapes \w and \W and Word Asserts \b and \B
3016         https://bugs.webkit.org/show_bug.cgi?id=158505
3017
3018         Reviewed by Geoffrey Garen.
3019
3020         This change makes it so that the CharacterClassEscape \w matches the inverse of
3021         \W and vice versa for unicode, ignore case RegExp's.
3022
3023         Before this change, both /\w/ui and /\W/ui RegExp's would match the characters
3024         k, K, s, S, \u017f (Latin Small Letter Long S) and \u212a (Kelvin Sign).
3025         This was due to how the ES6 standard defined matching of character classes
3026         specifically that the abstract operation "Canonicalize()" is called for the
3027         character to be matched AND for the characters in the character class we are
3028         matching against.  This change is to make \W always be the inverse of \w.
3029         It is still the case that the characters that match against \w changes
3030         depending on a regular expression's flags.
3031
3032         The only real changes occur for regular expressions with both the unicode and
3033         ignore case flags set.  Updated the character class generator to make 
3034         nonwordUnicodeIgnoreCaseChar not include k, K, s, S, \u017f and \u212a.
3035         Changed BytecodePattern.wordcharCharacterClass to use the correct
3036         word character class for the flags.  Simplfied character class set up in
3037         in the pattern to use m_pattern.wordUnicodeIgnoreCaseCharCharacterClass and
3038         invert as appropriate when unicode and ignore case are both set.
3039
3040         * create_regex_tables:
3041         * yarr/YarrInterpreter.h:
3042         (JSC::Yarr::BytecodePattern::BytecodePattern):
3043         * yarr/YarrPattern.cpp:
3044         (JSC::Yarr::YarrPatternConstructor::atomBuiltInCharacterClass):
3045
3046 2016-06-25  Keith Miller  <keith_miller@apple.com>
3047
3048         DFGByteCodeParsing does not handle calling the Object constructor with no arguments correctly
3049         https://bugs.webkit.org/show_bug.cgi?id=159117
3050         <rdar://problem/26996781>
3051
3052         Reviewed by Saam Barati.
3053
3054         DFGByteCodeParsing always assumed there would be an argument to the Object constructor.
3055         This is clearly not always the case and we should be able to handle it.
3056
3057         * dfg/DFGByteCodeParser.cpp:
3058         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
3059         * tests/stress/indirect-call-object-constructor-with-no-arguments.js: Added.
3060         (let.foo.Object.test):
3061
3062 2016-06-24  Filip Pizlo  <fpizlo@apple.com>
3063
3064         B3 should die sooner if a Value has the wrong number of children
3065         https://bugs.webkit.org/show_bug.cgi?id=159108
3066
3067         Reviewed by Mark Lam.
3068         
3069         I've been looking at a bug (rdar://problem/26500743) that's about a Vector OOB crash in
3070         ReduceStrength::rangeFor(). The only Vector accesses are to Value::m_children, and all of
3071         the accesses in rangeFor() are for child(0) or child(1) of binary arithmetic opcodes.
3072         Clearly those should never go out-of-bounds.
3073         
3074         Maybe we have horrible memory corruption. Or maybe some path creates a Value with the
3075         wrong number of children, and that path is not tested by any of our tests. This patch adds
3076         release assertions that will catch the latter.
3077         
3078         I've tested this a lot. It's not a regression on our benchmarks.
3079
3080         * b3/B3Opcode.h:
3081         * b3/B3Value.cpp:
3082         (JSC::B3::Value::dumpMeta):
3083         (JSC::B3::Value::typeFor):
3084         (JSC::B3::Value::badOpcode):
3085         (JSC::B3::Value::checkOpcode): Deleted.
3086         * b3/B3Value.h:
3087
3088 2016-06-24  Mark Lam  <mark.lam@apple.com>
3089
3090         [JSC] Error prototypes are called on remote scripts.
3091         https://bugs.webkit.org/show_bug.cgi?id=52192
3092
3093         Reviewed by Keith Miller.
3094
3095         Added a sanitizedToString() to the Error instance object so that it can be used
3096         to get an error string without invoking getters and proxies.
3097
3098         * runtime/ErrorInstance.cpp:
3099         (JSC::ErrorInstance::finishCreation):
3100         (JSC::ErrorInstance::sanitizedToString):
3101         * runtime/ErrorInstance.h:
3102         (JSC::ErrorInstance::createStructure):
3103         (JSC::ErrorInstance::runtimeTypeForCause):
3104         (JSC::ErrorInstance::clearRuntimeTypeForCause):
3105
3106 2016-06-24  Commit Queue  <commit-queue@webkit.org>
3107
3108         Unreviewed, rolling out r202443.
3109         https://bugs.webkit.org/show_bug.cgi?id=159105
3110
3111         Introduced memory corruption crashes (Requested by ap on
3112         #webkit).
3113
3114         Reverted changeset:
3115
3116         "Web Inspector: CRASH in backend at
3117         Inspector::HeapFrontendDispatcher::garbageCollected + 552 when
3118         closing frontend/inspected page"
3119         https://bugs.webkit.org/show_bug.cgi?id=159075
3120         http://trac.webkit.org/changeset/202443
3121
3122 2016-06-24  Brian Burg  <bburg@apple.com>
3123
3124         Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
3125         https://bugs.webkit.org/show_bug.cgi?id=159075
3126         <rdar://problem/26094341>
3127
3128         Reviewed by Joseph Pecoraro.
3129
3130         Move the asynchronous work to a task class that can be cancelled when the
3131         heap agent is reset, disabled or destroyed.
3132
3133         * inspector/agents/InspectorHeapAgent.cpp:
3134         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
3135         (Inspector::SendGarbageCollectionEventsTask::addGarbageCollection):
3136         (Inspector::SendGarbageCollectionEventsTask::reset):
3137         (Inspector::SendGarbageCollectionEventsTask::timerFired):
3138         Added. This holds onto GarbageCollection objects that need to be sent asynchronously.
3139         It uses the RunLoop variant of Timer and can queue multiple pending objects to be sent.
3140
3141         (Inspector::InspectorHeapAgent::InspectorHeapAgent):
3142         (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
3143         (Inspector::InspectorHeapAgent::disable):
3144         Reset the task when disabling or tearing down the agent so the timer doesn't fire after destruction.
3145
3146         (Inspector::InspectorHeapAgent::didGarbageCollect):
3147         Send the object to the task to be dispatched asynchronously.
3148
3149         * inspector/agents/InspectorHeapAgent.h:
3150
3151 2016-06-24  Commit Queue  <commit-queue@webkit.org>
3152
3153         Unreviewed, rolling out r202413.
3154         https://bugs.webkit.org/show_bug.cgi?id=159097
3155
3156         Broke many JSC tests (Requested by ap on #webkit).
3157
3158         Reverted changeset:
3159
3160         "[JSC] Implement isFinite / isNaN in JS and make DFG ToNumber
3161         accept non number values"
3162         https://bugs.webkit.org/show_bug.cgi?id=154022
3163         http://trac.webkit.org/changeset/202413
3164
3165 2016-06-23  Benjamin Poulain  <bpoulain@apple.com>
3166
3167         OOM Assertion failure in Array.prototype.toString
3168         https://bugs.webkit.org/show_bug.cgi?id=158793
3169
3170         Reviewed by Saam Barati.
3171
3172         JSString::create() taking a StringImpl was using a signed integer
3173         for the length of the string.
3174         The problem is StringImpl uses an unsigned integer. When a large string
3175         was passed to JSString, the signed integer would be negative and crash
3176         JSString.
3177
3178         * runtime/JSString.h:
3179         (JSC::JSString::create):
3180
3181 2016-06-23  Joseph Pecoraro  <pecoraro@apple.com> and Yusuke Suzuki  <utatane.tea@gmail.com>
3182
3183         [JSC] Implement isFinite / isNaN in JS and make DFG ToNumber accept non number values
3184         https://bugs.webkit.org/show_bug.cgi?id=154022
3185
3186         Reviewed by Filip Pizlo.
3187
3188         We aim at optimizing @toInteger operation.
3189         While it still has an unoptimized part[1], this patch should be a first step.
3190
3191         We introduce the @toNumber builtin intrinsic operation.
3192         This converts the given value to the JS number by emitting op_to_number bytecode.
3193         Previously @toInteger called C++ @Number constructor for that purpose.
3194
3195         And in DFG, op_to_number is converted to DFG ToNumber node.
3196         During DFG, we attempt to convert this to edge filtering and Identity, but if we fail,
3197         we just fall back to calling the C++ function.
3198
3199         To utilize ToNumber in user-land side, we add a path attempting to convert Number constructor calls
3200         to ToNumber DFG nodes. This conversion is useful because `Number(value)` is used to convert a value to a number in JS.
3201
3202         Before this patch, we emit simple edge filtering (NumberUse) instead of emitting DFG node like ToNumber for op_to_number.
3203         But emitting ToNumber is useful, because in the case of `Number(value)`, considering `value` may not be a number is reasonable.
3204
3205         By leveraging @toNumber operation, we rewrite Number.{isFinite, isNaN}, global.{isFinite, isNaN} and @toInteger.
3206
3207         ToNumber DFG node has a value profiling. This profiling is leveraged to determine the result number type of the ToNumber operation.
3208         This value profiling is provided from either NumberConstructor's call operation or op_to_number.
3209
3210         The results (with the added performance tests) show that, while existing cases are performance neutral, the newly added cases gain the performance benefit.
3211         And ASMBench/n-body.c also shows stable ~2% progression.
3212
3213         [1]: https://bugs.webkit.org/show_bug.cgi?id=153738
3214
3215         * CMakeLists.txt:
3216         * DerivedSources.make:
3217         * JavaScriptCore.xcodeproj/project.pbxproj:
3218         * builtins/BuiltinNames.h:
3219         * builtins/GlobalObject.js:
3220         (globalPrivate.isFinite):
3221         (globalPrivate.isNaN):
3222         (globalPrivate.toInteger): Deleted.
3223         (globalPrivate.toLength): Deleted.
3224         (globalPrivate.isDictionary): Deleted.
3225         (globalPrivate.speciesGetter): Deleted.
3226         (globalPrivate.speciesConstructor): Deleted.
3227         * builtins/GlobalOperations.js: Copied from Source/JavaScriptCore/builtins/GlobalObject.js.
3228         (globalPrivate.toInteger):
3229         (globalPrivate.toLength):
3230         (globalPrivate.isDictionary):
3231         (globalPrivate.speciesGetter):
3232         (globalPrivate.speciesConstructor):
3233         * builtins/NumberConstructor.js: Added.
3234         (isFinite):
3235         (isNaN):
3236         * bytecode/BytecodeIntrinsicRegistry.cpp:
3237         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
3238         * bytecode/BytecodeIntrinsicRegistry.h:
3239         * bytecode/BytecodeList.json:
3240         * bytecode/CodeBlock.cpp:
3241         (JSC::CodeBlock::dumpBytecode):
3242         (JSC::CodeBlock::finishCreation):
3243         * bytecompiler/BytecodeGenerator.cpp:
3244         (JSC::BytecodeGenerator::emitUnaryOp):
3245         (JSC::BytecodeGenerator::emitUnaryOpProfiled):
3246         * bytecompiler/BytecodeGenerator.h:
3247         (JSC::BytecodeGenerator::emitToNumber):
3248         * bytecompiler/NodesCodegen.cpp:
3249         (JSC::BytecodeIntrinsicNode::emit_intrinsic_toNumber):
3250         (JSC::UnaryPlusNode::emitBytecode):
3251         * dfg/DFGAbstractInterpreterInlines.h:
3252         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3253         * dfg/DFGByteCodeParser.cpp:
3254         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
3255         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
3256         (JSC::DFG::ByteCodeParser::parseBlock):
3257         We use `getPrediction()` to retrieve the heap prediction from the to_number bytecode.
3258         According to the benchmark results, choosing `getPredictionWithoutOSRExit()` causes performance regression (1.5%) in kraken stanford-crypto-aes.
3259
3260         * dfg/DFGClobberize.h:
3261         (JSC::DFG::clobberize):
3262         * dfg/DFGConstantFoldingPhase.cpp:
3263         (JSC::DFG::ConstantFoldingPhase::foldConstants):
3264         * dfg/DFGDoesGC.cpp:
3265         (JSC::DFG::doesGC):
3266         * dfg/DFGFixupPhase.cpp:
3267         (JSC::DFG::FixupPhase::fixupNode):
3268         (JSC::DFG::FixupPhase::fixupToNumber):
3269         ToNumber tells its predicted type by its heap prediction. So the fixup phase need to consider about it.
3270         If the heap prediction is Int32, we should attempt to convert the child value to Int32.
3271         Without this, misc-bugs-847389-jpeg2000 in assorted tests poses 53% regression.
3272
3273         * dfg/DFGNode.h:
3274         (JSC::DFG::Node::hasHeapPrediction):
3275         * dfg/DFGNodeType.h:
3276         * dfg/DFGOperations.cpp:
3277         * dfg/DFGOperations.h:
3278         * dfg/DFGPredictionPropagationPhase.cpp:
3279         Alway rely on the heap prediction.
3280
3281         * dfg/DFGSafeToExecute.h:
3282         (JSC::DFG::safeToExecute):
3283         * dfg/DFGSpeculativeJIT32_64.cpp:
3284         (JSC::DFG::SpeculativeJIT::compile):
3285         As of 64bit version, we carefully manage the register reuse. The largest difference between 32bit and 64bit is
3286         `branchIfNotNumber()` requires the temporary register. We should not use the result registers for that since
3287         it may be reuse the argument registers and it can break the argument registers before using them to call the operation.
3288         Currently, we allocate the additional temporary register for that scratch register.
3289
3290         * dfg/DFGSpeculativeJIT64.cpp:
3291         (JSC::DFG::SpeculativeJIT::compile):
3292         Reuse the argument register for the result if possible. And manually decrement the use count in the middle of the node.
3293         This is similar technique used in ToPrimitive. Typically, the child of ToNumber is only used by this ToNumber node since
3294         we would like to perform the type conversion onto this child node here. So this careful register reuse effectively removes
3295         the spills to call the operation. The example of the actually emitted code is the following.
3296
3297         76:<!2:loc11>     ToNumber(Untyped:@68, JS|MustGen|UseAsOther, DoubleimpurenanTopEmpty, R:World, W:Heap, Exits, ClobbersExit, bc#48)  predicting DoubleimpurenanTopEmpty
3298             0x7f986d5fe693: test %rax, %r14
3299             0x7f986d5fe696: jz 0x7f986d5fe6a1
3300             0x7f986d5fe69c: jmp 0x7f986d5fe6d1
3301             0x7f986d5fe6a1: mov %rax, %rsi
3302             0x7f986d5fe6a4: mov %rbp, %rdi
3303             0x7f986d5fe6a7: mov $0x2, 0x24(%rbp)
3304             0x7f986d5fe6ae: mov $0x7f98711ea5f0, %r11
3305             0x7f986d5fe6b8: call *%r11
3306             0x7f986d5fe6bb: mov $0x7f982d3f72d0, %r11
3307             0x7f986d5fe6c5: mov (%r11), %r11
3308             0x7f986d5fe6c8: test %r11, %r11
3309             0x7f986d5fe6cb: jnz 0x7f986d5fe88c
3310
3311         It effectively removes the unnecessary spill to call the operation!
3312
3313         * ftl/FTLCapabilities.cpp:
3314         (JSC::FTL::canCompile):
3315         * ftl/FTLLowerDFGToB3.cpp:
3316         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3317         (JSC::FTL::DFG::LowerDFGToB3::compileToNumber):
3318         (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
3319         * jit/AssemblyHelpers.h:
3320         (JSC::AssemblyHelpers::branchIfNumber):
3321         (JSC::AssemblyHelpers::branchIfNotNumber):
3322         * jit/JITOpcodes.cpp:
3323         (JSC::JIT::emit_op_to_number):
3324         * jit/JITOpcodes32_64.cpp:
3325         (JSC::JIT::emit_op_to_number):
3326         * llint/LowLevelInterpreter32_64.asm:
3327         * llint/LowLevelInterpreter64.asm:
3328         * parser/Nodes.h:
3329         (JSC::UnaryOpNode::opcodeID):
3330         * runtime/CommonSlowPaths.cpp:
3331         (JSC::SLOW_PATH_DECL):
3332         * runtime/JSGlobalObject.cpp:
3333         (JSC::JSGlobalObject::init):
3334         * runtime/JSGlobalObjectFunctions.cpp:
3335         (JSC::globalFuncIsNaN): Deleted.
3336         (JSC::globalFuncIsFinite): Deleted.
3337         * runtime/JSGlobalObjectFunctions.h:
3338         * runtime/MathCommon.h:
3339         (JSC::maxSafeInteger):
3340         (JSC::minSafeInteger):
3341         * runtime/NumberConstructor.cpp:
3342         (JSC::NumberConstructor::finishCreation):
3343         (JSC::numberConstructorFuncIsFinite): Deleted.
3344         (JSC::numberConstructorFuncIsNaN): Deleted.
3345         * runtime/NumberConstructor.h:
3346         * tests/stress/Number-isNaN-basics.js: Added.
3347         (numberIsNaNOnInteger):
3348         (testNumberIsNaNOnIntegers):
3349         (verifyNumberIsNaNOnIntegerWithOtherTypes):
3350         (numberIsNaNOnDouble):
3351         (testNumberIsNaNOnDoubles):
3352         (verifyNumberIsNaNOnDoublesWithOtherTypes):
3353         (numberIsNaNNoArguments):
3354         (numberIsNaNTooManyArguments):
3355         (testNumberIsNaNOnConstants):
3356         (numberIsNaNStructTransition):
3357         (Number.isNaN):
3358         * tests/stress/global-is-finite.js: Added.
3359         (shouldBe):
3360         * tests/stress/global-is-nan.js: Added.
3361         (shouldBe):
3362         * tests/stress/global-isNaN-basics.js: Added.
3363         (isNaNOnInteger):
3364         (testIsNaNOnIntegers):
3365         (verifyIsNaNOnIntegerWithOtherTypes):
3366         (isNaNOnDouble):
3367         (testIsNaNOnDoubles):
3368         (verifyIsNaNOnDoublesWithOtherTypes):
3369         (verifyIsNaNOnCoercedTypes):
3370         (isNaNNoArguments):
3371         (isNaNTooManyArguments):
3372         (testIsNaNOnConstants):
3373         (isNaNTypeCoercionSideEffects):
3374         (i.value.isNaNTypeCoercionSideEffects.valueOf):
3375         (isNaNStructTransition):
3376         (isNaN):
3377         * tests/stress/number-is-finite.js: Added.
3378         (shouldBe):
3379         (test2):
3380         (test3):
3381         * tests/stress/number-is-nan.js: Added.
3382         (shouldBe):
3383         (test2):
3384         (test3):
3385         * tests/stress/to-number-basics.js: Added.
3386         (shouldBe):
3387         * tests/stress/to-number-convert-identity-without-execution.js: Added.
3388         (shouldBe):
3389         (object.valueOf):
3390         (valueOf):
3391         * tests/stress/to-number-int52.js: Added.
3392         (shouldBe):
3393         (object.valueOf):
3394         * tests/stress/to-number-intrinsic-convert-to-identity-without-execution.js: Added.
3395         (shouldBe):
3396         (object.valueOf):
3397         (valueOf):
3398         * tests/stress/to-number-intrinsic-int52.js: Added.
3399         (shouldBe):
3400         (object.valueOf):
3401         * tests/stress/to-number-intrinsic-object-without-execution.js: Added.
3402         (shouldBe):
3403         (object.valueOf):
3404         * tests/stress/to-number-intrinsic-value-profiling.js: Added.
3405         (shouldBe):
3406         (object.valueOf):
3407         * tests/stress/to-number-object-without-execution.js: Added.
3408         (shouldBe):
3409         (object.valueOf):
3410         * tests/stress/to-number-object.js: Added.
3411         (shouldBe):
3412         (test12):
3413         (object1.valueOf):
3414         (test2):
3415         (test22):
3416         (object2.valueOf):
3417         (test3):
3418         (test32):
3419         (object3.valueOf):
3420         * tests/stress/to-number-value-profiling.js: Added.
3421         (shouldBe):
3422         (object.valueOf):
3423
3424 2016-06-23  Saam Barati  <sbarati@apple.com>
3425
3426         DFGSpeculativeJIT's m_slowPathLambdas should restore the current node field and DFG OSR entry functions should use DeferGCForAWhile instead of DeferGC
3427         https://bugs.webkit.org/show_bug.cgi?id=159064
3428         <rdar://problem/26599119>
3429
3430         Reviewed by Filip Pizlo.
3431
3432         The DFG has a list of m_slowPathLambdas that are code generators it emits
3433         amongst its slow paths. These lambdas, however, did not update the m_currentNode field.
3434         This caused us to use whatever Node happened to be used as the currentNode at the time
3435         we call the slowPathLambda. This means the wrong CallSiteIndex was stored into the call
3436         frame when we made a call. This may lead to a crash if the CallSiteIndex corresponds to
3437         the wrong CodeOrigin. For example, the wrong CodeOrigin could have an InlineCallFrame with
3438         a calleeRecovery that will not be in sync with the current stack state. Trying
3439         to recover that callee will often lead to a crash. The solution is to update
3440         m_currentNode to the DFG::Node* it corresponds to when emitting these slowPathLambdas.
3441
3442         I found this bug because we were inside this bad state when calling an operation
3443         that happened to have a DeferGC. When this DeferGC actually GCed, it would
3444         take a StackTrace, which would lead to a crash because we were updating
3445         ShadowChicken with vm.topCallFrame. It just so happened that the CallSiteIndex
3446         in the call frame in this program corresponded to an InlineCallFrame with a calleeRecover.
3447         However, this CallSiteIndex didn't correspond to the actual state of execution
3448         of the program. I'm adding new options to make reproducing DeferGC related
3449         bugs easier by making DeferGC force a GC according to some probability. To
3450         always have DeferGC force a GC, you can set that probability to 1.
3451
3452         There is a second bug that I discovered after solving the above bug. We were
3453         using DeferGC instead of DeferGCForAWhile in the OSR entry related functions
3454         in the DFG. This would cause us to take a stack trace when the call frame was
3455         in an inconsistent state. For example, the operation would call FTL::prepareOSREntry,
3456         which would replace the DFG CodeBlock in the call frame with the FTL CodeBlock.
3457         However, we wouldn't update the CallSiteIndex to correspond to an FTL CallSiteIndex.
3458         This would lead to a crash when taking a stack trace. The solution is to prevent
3459         stack traces from being taken when the program is in this state by using
3460         DeferGCForAWhie instead of DeferGC.
3461
3462         * dfg/DFGOperations.cpp:
3463         * dfg/DFGSpeculativeJIT.cpp:
3464         (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
3465         (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
3466         * dfg/DFGSpeculativeJIT.h:
3467         * heap/Heap.h:
3468         * heap/HeapInlines.h:
3469         (JSC::Heap::collectIfNecessaryOrDefer):
3470         (JSC::Heap::collectAccordingToDeferGCProbability):
3471         (JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
3472         (JSC::Heap::markListSet):
3473         * runtime/Options.cpp:
3474         (JSC::recomputeDependentOptions):
3475         (JSC::Options::initialize):
3476         * runtime/Options.h:
3477         * tests/stress/slow-path-generator-updating-current-node-dfg.js: Added.
3478         (foo):
3479         (bar):
3480
3481 2016-06-23  Filip Pizlo  <fpizlo@apple.com>
3482
3483         Failing baseline JIT compilation of a code block and then trying to compile it from OSR from DFG/FTL will corrupt the CodeBlock
3484         https://bugs.webkit.org/show_bug.cgi?id=158806
3485
3486         Reviewed by Saam Barati.
3487         
3488         If we try to compile a CodeBlock that we already tried compiling in the past then we need
3489         to clean up the data structures that were partly filled in by the failed compile. That
3490         causes some races, since the DFG may be trying to parse those data structures while we are
3491         clearing them. This patch introduces such a clean-up (CodeBlock::resetJITData()) and fixes
3492         the races.
3493
3494         * bytecode/CodeBlock.cpp:
3495         (JSC::CodeBlock::dumpBytecode):
3496         (JSC::CodeBlock::getStubInfoMap):
3497         (JSC::CodeBlock::getCallLinkInfoMap):
3498         (JSC::CodeBlock::getByValInfoMap):
3499         (JSC::CodeBlock::getCallLinkInfoForBytecodeIndex):
3500         (JSC::CodeBlock::resetJITData):
3501         (JSC::CodeBlock::visitOSRExitTargets):
3502         (JSC::CodeBlock::setSteppingMode):
3503         (JSC::CodeBlock::addRareCaseProfile):
3504         (JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
3505         (JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset):
3506         (JSC::CodeBlock::resultProfileForBytecodeOffset):
3507         (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset):
3508         (JSC::CodeBlock::couldTakeSpecialFastCase):
3509         (JSC::CodeBlock::ensureResultProfile):
3510         * bytecode/CodeBlock.h:
3511         (JSC::CodeBlock::getFromAllValueProfiles):
3512         (JSC::CodeBlock::numberOfRareCaseProfiles):
3513         (JSC::CodeBlock::numberOfResultProfiles):
3514         (JSC::CodeBlock::numberOfArrayProfiles):
3515         (JSC::CodeBlock::arrayProfiles):
3516         (JSC::CodeBlock::addRareCaseProfile): Deleted.
3517         (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset): Deleted.
3518         (JSC::CodeBlock::couldTakeSpecialFastCase): Deleted.
3519         * dfg/DFGByteCodeParser.cpp:
3520         (JSC::DFG::ByteCodeParser::makeSafe):
3521         * dfg/DFGGraph.cpp:
3522         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
3523         * jit/JIT.cpp:
3524         (JSC::JIT::link):
3525         * jit/JITWorklist.cpp:
3526         (JSC::JITWorklist::compileNow):
3527
3528 2016-06-23  Joseph Pecoraro  <pecoraro@apple.com>
3529
3530         Web Inspector: Memory Timeline sometimes shows impossible value for bmalloc size (underflowed)
3531         https://bugs.webkit.org/show_bug.cgi?id=158110
3532         <rdar://problem/26498584>
3533
3534         Reviewed by Andreas Kling.
3535
3536         * heap/Heap.cpp:
3537         (JSC::Heap::willStartCollection):
3538         (JSC::Heap::didFinishCollection):
3539         * heap/Heap.h:
3540         (JSC::Heap::externalMemorySize):
3541         * heap/HeapInlines.h:
3542         (JSC::Heap::reportExternalMemoryVisited):
3543         Keep count of external memory we visit.
3544
3545         * heap/SlotVisitor.h:
3546         * heap/SlotVisitorInlines.h:
3547         (JSC::SlotVisitor::reportExternalMemoryVisited):
3548         Report external memory visited like we do extra memory, since
3549         it will be some subset of extra memory that is external.
3550
3551 2016-06-23  Joseph Pecoraro  <pecoraro@apple.com>
3552
3553         Web Inspector: Snapshots should be cleared at some point
3554         https://bugs.webkit.org/show_bug.cgi?id=157907
3555         <rdar://problem/26373610>
3556
3557         Reviewed by Timothy Hatcher.
3558
3559         * heap/HeapSnapshotBuilder.h:
3560         * heap/HeapSnapshotBuilder.cpp:
3561         (JSC::HeapSnapshotBuilder::resetNextAvailableObjectIdentifier):
3562         Provide a way to reset the object identifier counter.
3563
3564         * inspector/agents/InspectorHeapAgent.h:
3565         * inspector/agents/InspectorHeapAgent.cpp:
3566         (Inspector::InspectorHeapAgent::clearHeapSnapshots):
3567         Make clearHeapSnapshots protected, so it can be called from a
3568         a PageHeapAgent on page navigations.
3569
3570 2016-06-22  Saam barati  <sbarati@apple.com>
3571
3572         TypeProfiler and TypeProfilerLog don't play nicely with the concurrent JIT
3573         https://bugs.webkit.org/show_bug.cgi?id=159037
3574         <rdar://problem/26935349>
3575
3576         Reviewed by Benjamin Poulain.
3577
3578         The primary focus of this patch is to make the concurrent
3579         baseline JIT work with the type profiler. We were clearing
3580         the type profiler log on the background baseline compiler
3581         thread which lead to bad things happening. This patch fixes
3582         this by processing the log before we launch the compile on
3583         a background thread.
3584
3585         Secondly, I audited the type profiler code inside the DFG,
3586         and found that we were doing some racy things. I haven't
3587         seen any crashes because of these things, but it is possible
3588         that they exist. We were grabbing a RefPtr to a TypeSet,
3589         even though TypeSet was RefCounted and not ThreadSafeRefCounted.
3590         This patch makes TypeSet ThreadSafeRefCounted. We were
3591         also copying a StructureSet while the execution thread could
3592         be augmenting the StructureSet. This patch puts changes to 
3593         TypeSet's StructureSet behind a ConcurrentJITLock.
3594
3595         I've also added two more large running tests that run with the
3596         type profiler enabled. These are here just to catch any major bugs
3597         in the type profiler implementation.
3598
3599         * jit/JIT.cpp:
3600         (JSC::JIT::compileWithoutLinking):
3601         (JSC::JIT::privateCompile):
3602         (JSC::JIT::privateCompileExceptionHandlers):
3603         (JSC::JIT::doMainThreadPreparationBeforeCompile):
3604         (JSC::JIT::frameRegisterCountFor):
3605         * jit/JIT.h:
3606         (JSC::JIT::compile):
3607         * jit/JITWorklist.cpp:
3608         (JSC::JITWorklist::Plan::Plan):
3609         (JSC::JITWorklist::Plan::compileInThread):
3610         * runtime/TypeSet.cpp:
3611         (JSC::TypeSet::addTypeInformation):
3612         (JSC::TypeSet::invalidateCache):
3613         * runtime/TypeSet.h:
3614         (JSC::TypeSet::create):
3615         (JSC::TypeSet::isEmpty):
3616         (JSC::TypeSet::seenTypes):
3617         (JSC::TypeSet::structureSet):
3618         * tests/typeProfiler/deltablue-for-of.js: Added.
3619         * tests/typeProfiler/getter-richards.js: Added.
3620
3621 2016-06-22  Keith Miller  <keith_miller@apple.com>
3622
3623         We should have a DFG intrinsic that checks if a value is a TypedArrayView
3624         https://bugs.webkit.org/show_bug.cgi?id=159048
3625
3626         Reviewed by Saam Barati.
3627
3628         This patch adds a new DFG Intrinsic that checks if a value is a TypedArrayView.
3629         The intrinsic, IsTypedArrayView, works in the same way that the other Is<insert-type>
3630         DFG nodes work. Additionally, a new builtin function isTypedArrayView has been added.
3631         These changes are needed to fix regressions in %TypedArray%.prototype.subarray.
3632
3633         * builtins/BuiltinNames.h:
3634         * dfg/DFGAbstractInterpreterInlines.h:
3635         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3636         * dfg/DFGByteCodeParser.cpp:
3637         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
3638         * dfg/DFGClobberize.h:
3639         (JSC::DFG::clobberize):
3640         * dfg/DFGDoesGC.cpp:
3641         (JSC::DFG::doesGC):
3642         * dfg/DFGFixupPhase.cpp:
3643         (JSC::DFG::FixupPhase::fixupNode):
3644         * dfg/DFGNodeType.h:
3645         * dfg/DFGPredictionPropagationPhase.cpp:
3646         * dfg/DFGSafeToExecute.h:
3647         (JSC::DFG::safeToExecute):
3648         * dfg/DFGSpeculativeJIT.cpp:
3649         (JSC::DFG::SpeculativeJIT::compileIsTypedArrayView):
3650         * dfg/DFGSpeculativeJIT.h:
3651         * dfg/DFGSpeculativeJIT32_64.cpp:
3652         (JSC::DFG::SpeculativeJIT::compile):
3653         * dfg/DFGSpeculativeJIT64.cpp:
3654         (JSC::DFG::SpeculativeJIT::compile):
3655         * ftl/FTLCapabilities.cpp:
3656         (JSC::FTL::canCompile):
3657         * ftl/FTLLowerDFGToB3.cpp:
3658         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3659         (JSC::FTL::DFG::LowerDFGToB3::compileIsTypedArrayView):
3660         (JSC::FTL::DFG::LowerDFGToB3::isTypedArrayView):
3661         * runtime/Intrinsic.h:
3662         * runtime/JSGlobalObject.cpp:
3663         (JSC::JSGlobalObject::init):
3664         * runtime/JSTypedArrayViewPrototype.cpp:
3665         (JSC::typedArrayViewPrivateFuncIsTypedArrayView):
3666         * runtime/JSTypedArrayViewPrototype.h:
3667         * tests/stress/istypedarrayview-intrinsic.js: Added.
3668         (makeFn):
3669         (typedArrays.forEach):
3670         (let.test):
3671         (test):
3672
3673 2016-06-21  Anders Carlsson  <andersca@apple.com>
3674
3675         Fix build.
3676
3677         * Configurations/FeatureDefines.xcconfig:
3678
3679 2016-06-21  Geoffrey Garen  <ggaren@apple.com>
3680
3681         Options::useImmortalObjects is not safe for conservative GC
3682         https://bugs.webkit.org/show_bug.cgi?id=158999
3683
3684         Reviewed by Geoffrey Garen.
3685
3686         useImmortalObjects set the mark bit to keep an object from being
3687         reallocated. This had the negative side-effect of convincing the
3688         conservative marker that the object was a valid and live cell, which
3689         would cause us to visit garbage.
3690
3691         * heap/Heap.cpp:
3692         (JSC::Heap::didFinishCollection):
3693         (JSC::Heap::resumeCompilerThreads):
3694         (JSC::Heap::setFullActivityCallback):
3695         (JSC::Heap::markDeadObjects): Deleted.
3696         * heap/Heap.h: Don't set the mark bit on a dead object. That's a bug in
3697         a conservative GC.
3698
3699         * heap/MarkedAllocator.cpp:
3700         (JSC::MarkedAllocator::retire): New helper.
3701
3702         (JSC::MarkedAllocator::reset): Automatically retire old blocks when
3703         we're doing the immortal objects thing. This has the effect of
3704         preserving memory for debugging because we never recycle a previously
3705         allocated block.
3706
3707 2016-06-21  Anders Carlsson  <andersca@apple.com>
3708
3709         Begin moving the Apple Pay code to the open source repository
3710         https://bugs.webkit.org/show_bug.cgi?id=158998
3711
3712         Reviewed by Tim Horton.
3713
3714         * Configurations/FeatureDefines.xcconfig:
3715         Add ENABLE_APPLE_PAY.
3716
3717 2016-06-21  Saam Barati  <sbarati@apple.com>
3718
3719         CodeBlock::shrinkToFit is racy
3720         https://bugs.webkit.org/show_bug.cgi?id=158994
3721         <rdar://problem/26920212>
3722
3723         Reviewed by Filip Pizlo.
3724
3725         To see why this is racy, consider the following scenario:
3726         - CodeBlock A is link()ing its baseline compile.
3727         - CodeBlock B is inlining A, and asks A for a result profile in DFGBytecodeParser.
3728         - The race occurs when the link() step of the baseline compile calls shrinkToFit
3729           on its m_resultProfiles field without grabbing a lock. This leads to a bad
3730           time because the DFG compile will be reading from that vector as it's getting
3731           changed by the baseline link() method.
3732
3733         This race has always existed, though the move to a concurrent baseline
3734         JIT has made it more likely to occur. The solution is to have CodeBlock::shrinkToFit
3735         grab its lock before shrinking the vector.
3736
3737         * bytecode/CodeBlock.cpp:
3738         (JSC::CodeBlock::shrinkToFit):
3739
3740 2016-06-21  David Kilzer  <ddkilzer@apple.com>
3741
3742         Migrate testair & testb3 settings from Xcode project to ToolExecutable.xcconfig
3743         <https://webkit.org/b/158989>
3744
3745         Reviewed by Andy Estes.
3746
3747         * Configurations/ToolExecutable.xcconfig:
3748         (CODE_SIGN_ENTITLEMENTS_ios_testair): Add from Xcode project.
3749         * JavaScriptCore.xcodeproj/project.pbxproj:
3750         (CODE_SIGN_ENTITLEMENTS_ios_testair): Move to
3751         ToolExecutable.xcconfig.
3752         (PRODUCT_NAME): Remove.  This variable is already set for both
3753         testair and testb3 since those build configurations use
3754         ToolExecutable.xcconfig as a base.
3755
3756 2016-06-21  Saam Barati  <sbarati@apple.com>
3757
3758         LLInt doesn't throw stack exception overflow from parent frame
3759         https://bugs.webkit.org/show_bug.cgi?id=158962
3760         <rdar://problem/26902188>
3761
3762         Reviewed by Filip Pizlo.
3763
3764         All JIT tiers will throw stack overflow exceptions from the parent frame.
3765         The LLInt, on the other hand, did not use to. I've changed the LLInt to be
3766         consistent with the JITs. The reason I found this bug is because we had a
3767         test that would give different results depending on if the function was compiled
3768         in the baseline or the LLInt. Since Filip recently landed the concurrent baseline
3769         JIT patch, this otherwise deterministic test became dependent on it being compiled
3770         in the LLInt or one of the JIT tiers. I've added a new test that is deterministic
3771         because it runs the test with --useJIT=false.
3772
3773         * llint/LLIntSlowPaths.cpp:
3774         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3775         * tests/stress/llint-stack-overflow-location.js: Added.
3776         (stackTraceDescription):
3777         (foo):
3778         (catch):
3779
3780 2016-06-21  David Kilzer  <ddkilzer@apple.com>
3781
3782         CODE_SIGN_ENTITLEMENTS should be applied to iOS Simulator builds
3783         <https://webkit.org/b/158990>
3784         <rdar://problem/26906273>
3785
3786         Reviewed by Dan Bernstein.
3787
3788         * Configurations/JSC.xcconfig:
3789         (CODE_SIGN_ENTITLEMENTS): Change [sdk=iphoneos*] to
3790         [sdk=iphone*] to apply setting to iOS Simulator as well.
3791         * Configurations/ToolExecutable.xcconfig:
3792         (CODE_SIGN_ENTITLEMENTS): Ditto.
3793
3794 2016-06-21  Keith Miller  <keith_miller@apple.com>
3795
3796         It should be easy to add a private global helper function for builtins
3797         https://bugs.webkit.org/show_bug.cgi?id=158893
3798
3799         Reviewed by Mark Lam.
3800
3801         This patch does two things. First it moves all the builtin names
3802         out of CommonIdentifiers and into BuiltinNames. This means that
3803         adding a new function to the Builtins does not require rebuilding
3804         all of JavaScriptCore. This patch also adds a new decorator to our
3805         builtins @privateGlobal that will automatically put the function
3806         on the global object. The name of the property will be the same as
3807         the private name of the function.
3808
3809         This patch, also, removes the JSArrayIterator.h/.cpp files
3810         as they no longer appear to be used in any real way. Finally,
3811         the builtins tests have been rebaselined. It appears this has
3812         not been done for a while so the expected files contain other
3813         changes.
3814
3815         * CMakeLists.txt:
3816         * JavaScriptCore.xcodeproj/project.pbxproj:
3817         * Scripts/builtins/builtins_generate_combined_header.py:
3818         (BuiltinsCombinedHeaderGenerator.generate_output):
3819         (generate_section_for_code_name_macro):
3820         (generate_section_for_global_private_code_name_macro):
3821         * Scripts/builtins/builtins_model.py:
3822         (BuiltinFunction.__init__):
3823         (BuiltinFunction.fromString):
3824         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
3825         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
3826         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
3827         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
3828         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
3829         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
3830         * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
3831         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
3832         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
3833         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
3834         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
3835         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
3836         * builtins/ArrayIteratorPrototype.js:
3837         * builtins/ArrayPrototype.js:
3838         * builtins/BuiltinNames.h:
3839         * builtins/GeneratorPrototype.js:
3840         * builtins/GlobalObject.js:
3841         * builtins/PromiseOperations.js:
3842         * builtins/RegExpPrototype.js:
3843         * builtins/StringPrototype.js:
3844         * bytecode/BytecodeIntrinsicRegistry.cpp:
3845         * bytecompiler/BytecodeGenerator.cpp:
3846         (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
3847         (JSC::BytecodeGenerator::expectedFunctionForIdentifier):
3848         (JSC::BytecodeGenerator::emitGetTemplateObject):
3849         (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
3850         (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
3851         (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
3852         (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
3853         (JSC::BytecodeGenerator::emitGeneratorStateChange):
3854         * bytecompiler/NodesCodegen.cpp:
3855         (JSC::emitHomeObjectForCallee):
3856         (JSC::emitPutHomeObject):
3857         (JSC::FunctionNode::emitBytecode):
3858         * dfg/DFGOperations.cpp:
3859         * inspector/JSInjectedScriptHost.cpp:
3860         (Inspector::JSInjectedScriptHost::subtype):
3861         (Inspector::JSInjectedScriptHost::getInternalProperties): Deleted.
3862         * parser/Lexer.cpp:
3863         (JSC::Lexer<LChar>::parseIdentifier):
3864         (JSC::Lexer<UChar>::parseIdentifier):
3865         * parser/Nodes.h:
3866         * parser/Parser.cpp:
3867         (JSC::Parser<LexerType>::createGeneratorParameters):
3868         (JSC::Parser<LexerType>::parseExportDeclaration):
3869         * runtime/ArrayIteratorPrototype.cpp:
3870         * runtime/ArrayIteratorPrototype.h:
3871         * runtime/ArrayPrototype.cpp:
3872         * runtime/CommonIdentifiers.cpp:
3873         (JSC::CommonIdentifiers::CommonIdentifiers): Deleted.
3874         * runtime/CommonIdentifiers.h:
3875         * runtime/CommonSlowPaths.cpp:
3876         (JSC::SLOW_PATH_DECL):
3877         * runtime/IntlDateTimeFormat.cpp:
3878         * runtime/IntlDateTimeFormatPrototype.cpp:
3879         (JSC::IntlDateTimeFormatPrototypeGetterFormat):
3880         (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
3881         * runtime/IntlNumberFormatPrototype.cpp:
3882         (JSC::IntlNumberFormatPrototypeGetterFormat):
3883         (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
3884         * runtime/IntlObjectInlines.h:
3885         (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
3886         * runtime/JSArrayIterator.cpp: Removed.
3887         (JSC::JSArrayIterator::finishCreation): Deleted