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