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