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