f64d324d81bb883ed86dde1af8023b99b76ae6da
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-03-22  Caitlin Potter  <caitp@igalia.com>
2
3         [JSC] correctly handle indexed properties in Object.getOwnPropertyDescriptors
4         https://bugs.webkit.org/show_bug.cgi?id=155563
5
6         Reviewed by Saam Barati.
7
8         * runtime/JSObject.h:
9         (JSC::JSObject::putOwnDataPropertyMayBeIndex):
10         * runtime/ObjectConstructor.cpp:
11         (JSC::objectConstructorGetOwnPropertyDescriptors):
12
13 2016-03-22  Saam Barati  <sbarati@apple.com>
14
15         We should FTL compile code when the debugger is enabled
16         https://bugs.webkit.org/show_bug.cgi?id=155740
17
18         Reviewed by Oliver Hunt.
19
20         There was no fundamental reason why we didn't support debugging
21         with the FTL. It looks like this was just an oversight. We had
22         a Breakpoint node in the DFG that amounted to a nop. By removing
23         this node, we now support debugging in the FTL. Anytime a breakpoint
24         is set, we will jettison any DFG/FTL CodeBlocks that contain the breakpoint
25         that was set.
26
27         * dfg/DFGAbstractInterpreterInlines.h:
28         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
29         * dfg/DFGByteCodeParser.cpp:
30         (JSC::DFG::ByteCodeParser::parseBlock):
31         * dfg/DFGClobberize.h:
32         (JSC::DFG::clobberize):
33         * dfg/DFGDoesGC.cpp:
34         (JSC::DFG::doesGC):
35         * dfg/DFGFixupPhase.cpp:
36         (JSC::DFG::FixupPhase::fixupNode):
37         * dfg/DFGNodeType.h:
38         * dfg/DFGPredictionPropagationPhase.cpp:
39         (JSC::DFG::PredictionPropagationPhase::propagate):
40         * dfg/DFGSafeToExecute.h:
41         (JSC::DFG::safeToExecute):
42         * dfg/DFGSpeculativeJIT32_64.cpp:
43         (JSC::DFG::SpeculativeJIT::compile):
44         * dfg/DFGSpeculativeJIT64.cpp:
45         (JSC::DFG::SpeculativeJIT::compile):
46
47 2016-03-22  Keith Miller  <keith_miller@apple.com>
48
49         REGRESSION(r197543): Use-after-free on storage/indexeddb/transaction-abort-private.html
50         https://bugs.webkit.org/show_bug.cgi?id=155067
51
52         Reviewed by Filip Pizlo.
53
54         GCIncommingRefCountedSets need to be finalized before we start
55         destructing members of the Heap object. Previously, we would
56         clear all our ArrayBuffer objects when the GCIncommingRefCountedSet
57         holding them was destroyed. However, ArrayBuffers have a weak
58         reference to their wrappers. When we would attempt to destroy the
59         ArrayBuffer object we would end up accessing the WeakImpl for
60         the weak reference, which had already been freed as we destroyed
61         our weak block. The solution to this is to move the old
62         GCIncommingRefCountedSet destructor functionality to a new
63         function lastChanceToFinalize. This function is called when
64         we finalize our other objects on Heap destruction.
65
66         * heap/GCIncomingRefCountedSet.h:
67         * heap/GCIncomingRefCountedSetInlines.h:
68         (JSC::GCIncomingRefCountedSet<T>::lastChanceToFinalize):
69         (JSC::GCIncomingRefCountedSet<T>::~GCIncomingRefCountedSet): Deleted.
70         * heap/Heap.cpp:
71         (JSC::Heap::lastChanceToFinalize):
72
73 2016-03-22  Per Arne Vollan  <peavo@outlook.com>
74
75         [Win] [64-bit] Remove MSVC 2013 FMA3 Bug Workaround
76         https://bugs.webkit.org/show_bug.cgi?id=141499
77
78         Reviewed by Brent Fulgham.
79
80         As we have moved on to VS2015, this workaround is no longer needed.
81
82         * API/tests/testapi.c:
83         (main):
84         * JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp:
85         (wWinMain):
86         * jsc.cpp:
87         (main):
88         * testRegExp.cpp:
89         (main):
90
91 2016-03-22  Michael Saboff  <msaboff@apple.com>
92
93         [ES6] Implement RegExp.prototype[@@match]
94         https://bugs.webkit.org/show_bug.cgi?id=155711
95
96         Reviewed by Filip Pizlo.
97
98         Implemented ES6 spec for String.prototype.match and RegExp.prototype[@@match].
99         Implemented both as builtins, with String.prototype.match calling 
100         RegExp.prototype[@@match].
101
102         For performance reasons, RegExp.prototype[@@match] has a C++ fast path when
103         RegExp.prototype.exec has not been overridden.  This fast path,
104         RegExpObject::matchGlobal, was taken from the prior StringPrototype::match.
105         It only handles global matches.
106
107         Added new test, stress/regexp-match.js.
108
109         Updated various tests for changes exception string and now passing ES6 behavior.
110
111         * CMakeLists.txt: 
112         * DerivedSources.make:
113         * JavaScriptCore.xcodeproj/project.pbxproj:
114         Added builtins/RegExpPrototype.js and eliminated RegExpPrototype.lut.h.
115
116         * builtins/RegExpPrototype.js: Added.
117         (match.advanceStringIndexUnicode): Helper.
118         (match): Implements RegExp.prototype[@@match].
119         * builtins/StringPrototype.js:
120         (match): Implements String.prototype.match.
121
122         * bytecode/BytecodeIntrinsicRegistry.cpp:
123         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
124         (JSC::BytecodeIntrinsicRegistry::lookup):
125         * bytecode/BytecodeIntrinsicRegistry.h:
126         * runtime/CommonIdentifiers.h:
127         Added Symbol.match and builtins @match and @exec.
128
129         * runtime/RegExpObject.cpp:
130         * runtime/RegExpObject.h:
131         * runtime/RegExpObjectInlines.h:
132         (JSC::RegExpObject::matchGlobal): Added.
133         (JSC::RegExpObject::advanceStringUnicode): Added helper.
134
135         * runtime/RegExpPrototype.cpp:
136         * runtime/RegExpPrototype.h:
137         (JSC::RegExpPrototype::RegExpPrototype):
138         (JSC::RegExpPrototype::finishCreation):
139         (JSC::RegExpPrototype::visitChildren):
140         (JSC::regExpProtoFuncMatchPrivate):
141         (JSC::RegExpPrototype::getOwnPropertySlot): Deleted.
142         (JSC::RegExpPrototype::create):
143         Restructured to create properties explicitly due to having two names for native regExpProtoFuncExec.
144
145         * runtime/StringPrototype.cpp:
146         (JSC::StringPrototype::finishCreation):
147         Made match a builtin.
148         Removed unused declaration of stringProtoFuncSearch() since it was made a builtin.
149
150         * tests/es6.yaml:
151         * tests/stress/regexp-match.js: Added.
152         (shouldBe):
153         (shouldThrow):
154         (errorKey.toString):
155         (primitive.of.primitives.shouldThrow):
156         (testRegExpMatch):
157         (testMatch):
158         (testBoth):
159         (alwaysUnmatch):
160
161 2016-03-22  Caitlin Potter  <caitp@igalia.com>
162
163         [JSC] allow duplicate property names returned from Proxy ownKeys() trap
164         https://bugs.webkit.org/show_bug.cgi?id=155560
165
166         Reviewed by Darin Adler.
167
168         Specification allows duplicate property names to be reported by the
169         Proxy ownKeys() trap --- and this is observable in any API which
170         operates on the returned list, such as Object.keys(),
171         Object.getOwnPropertyNames(), Object.getOwnPropertySymbols(), or
172         Object.getOwnPropertyDescriptors().
173
174         * runtime/PropertyNameArray.h:
175         (JSC::PropertyNameArray::addUnchecked):
176         (JSC::PropertyNameArray::add):
177         (JSC::PropertyNameArray::addKnownUnique): Deleted.
178         * runtime/ProxyObject.cpp:
179         (JSC::ProxyObject::performGetOwnPropertyNames):
180         * runtime/Structure.cpp:
181         (JSC::Structure::getPropertyNamesFromStructure):
182
183 2016-03-21  Yusuke Suzuki  <utatane.tea@gmail.com>
184
185         [JSC] Clean up Math.floor thunk and use SSE round instruction
186         https://bugs.webkit.org/show_bug.cgi?id=155705
187
188         Reviewed by Geoffrey Garen.
189
190         SSE now allow us to use round instruction to implement Math.floor.
191         MacroAssembler's floorDouble is now only used in ARM64, but it can be allowed in x86 SSE.
192
193         * jit/ThunkGenerators.cpp:
194         (JSC::floorThunkGenerator):
195
196 2016-03-21  Konstantin Tokarev  <annulen@yandex.ru>
197
198         Fixed compilation with GCC 4.8.
199         https://bugs.webkit.org/show_bug.cgi?id=155698
200
201         Reviewed by Alexey Proskuryakov.
202
203         GCC 4.8 does not allow aggregate initialization for type with deleted
204         constructor, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52707.
205
206         * dfg/DFGCSEPhase.cpp: Added ctor for ImpureDataSlot.
207
208 2016-03-21  Joonghun Park  <jh718.park@samsung.com>
209
210         [JSC] Add ArrayBuffer::tryCreate and change the callsites where it is needed
211         https://bugs.webkit.org/show_bug.cgi?id=155328
212
213         Reviewed by Darin Adler.
214
215         * API/JSTypedArray.cpp:
216         (JSObjectMakeTypedArray):
217         (JSObjectMakeArrayBufferWithBytesNoCopy):
218         * runtime/ArrayBuffer.h:
219         (JSC::ArrayBuffer::create):
220         (JSC::ArrayBuffer::tryCreate):
221         (JSC::ArrayBuffer::createUninitialized):
222         (JSC::ArrayBuffer::tryCreateUninitialized):
223         (JSC::ArrayBuffer::createInternal):
224         * runtime/GenericTypedArrayViewInlines.h:
225         (JSC::GenericTypedArrayView<Adaptor>::create):
226         (JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
227         * runtime/JSArrayBufferConstructor.cpp:
228         (JSC::constructArrayBuffer):
229
230 2016-03-20  Dan Bernstein  <mitz@apple.com>
231
232         [Mac] Determine TARGET_MAC_OS_X_VERSION_MAJOR from MACOSX_DEPLOYMENT_TARGET rather than from MAC_OS_X_VERSION_MAJOR
233         https://bugs.webkit.org/show_bug.cgi?id=155707
234         <rdar://problem/24980691>
235
236         Reviewed by Darin Adler.
237
238         * Configurations/Base.xcconfig: Set TARGET_MAC_OS_X_VERSION_MAJOR based on the last
239           component of MACOSX_DEPLOYMENT_TARGET.
240         * Configurations/DebugRelease.xcconfig: For engineering builds, preserve the behavior of
241           TARGET_MAC_OS_X_VERSION_MAJOR being the host’s OS version.
242
243 2016-03-20  Michael Saboff  <msaboff@apple.com>
244
245         Crash in stress/regexp-matches-array-slow-put.js due to stomping on memory when having bad time
246         https://bugs.webkit.org/show_bug.cgi?id=155679
247
248         Reviewed by Saam Barati.
249
250         Allocate out of line storage based on what the structure says it needs
251         in JSArray::tryCreateUninitialized.
252
253         * runtime/JSArray.h:
254         (JSC::JSArray::tryCreateUninitialized):
255
256 2016-03-20  Joseph Pecoraro  <pecoraro@apple.com>
257
258         Crash on DFG::WorkList thread in JSC::Heap::isCollecting for destroyed Web Worker
259         https://bugs.webkit.org/show_bug.cgi?id=155678
260         <rdar://problem/25251439>
261
262         Reviewed by Filip Pizlo.
263
264         This fixes a crash that we saw with GuardMalloc. If the Plan was
265         Cancelled it may not be safe to access the VM. If the Plan was
266         cancelled we are just going to bail anyways, so keep the ASSERT but
267         short-circuit if the plan was Cancelled.
268
269         * dfg/DFGWorklist.cpp:
270         (JSC::DFG::Worklist::runThread):
271
272 2016-03-20  Dan Bernstein  <mitz@apple.com>
273
274         Update build settings
275
276         Rubber-stamped by Andy Estes.
277
278         * Configurations/DebugRelease.xcconfig:
279         * Configurations/FeatureDefines.xcconfig:
280         * Configurations/Version.xcconfig:
281
282 2016-03-19  Skachkov Oleksandr  <gskachkov@gmail.com>
283
284         [ES6] Arrow function syntax. Update syntax error text 'super is only valid inside functions' to more suitable
285         https://bugs.webkit.org/show_bug.cgi?id=155491
286
287         Reviewed by Saam Barati.
288
289         Current message 'super is only valid inside of funcitons' is not correct 
290         after patch for https://bugs.webkit.org/show_bug.cgi?id=153864 because 
291         it is allow to use 'super' in eval. Current patch replace old message by
292         'Super is only valid inside functions or 'eval' inside a function' and 
293         fix tests that rely on this message.
294
295         * parser/Parser.cpp:
296         (JSC::Parser<LexerType>::parseMemberExpression):
297         * tests/stress/generator-with-super.js:
298         (shouldThrow):
299         * tests/stress/modules-syntax-error.js:
300         * tests/stress/super-in-lexical-scope.js:
301         * tests/stress/tagged-templates-syntax.js:
302
303 2016-03-19  Mark Lam  <mark.lam@apple.com>
304
305         ES6 spec requires that ErrorPrototype not be an Error object.
306         https://bugs.webkit.org/show_bug.cgi?id=155680
307
308         Reviewed by Michael Saboff.
309
310         The ES6 spec states that Error.prototype should not be an instance of Error:
311         https://tc39.github.io/ecma262/#sec-properties-of-the-error-prototype-object
312
313         "The Error prototype object is an ordinary object. It is not an Error instance
314         and does not have an [[ErrorData]] internal slot."
315
316         This patch changes ErrorPrototype to conform to the above specification.
317
318         * runtime/ErrorConstructor.cpp:
319         (JSC::ErrorConstructor::finishCreation):
320         * runtime/ErrorPrototype.cpp:
321         (JSC::ErrorPrototype::ErrorPrototype):
322         (JSC::ErrorPrototype::finishCreation):
323         (JSC::ErrorPrototype::getOwnPropertySlot):
324         * runtime/ErrorPrototype.h:
325         (JSC::ErrorPrototype::create):
326
327         * runtime/NativeErrorConstructor.cpp:
328         (JSC::NativeErrorConstructor::finishCreation):
329         * runtime/NativeErrorPrototype.cpp:
330         (JSC::NativeErrorPrototype::NativeErrorPrototype):
331         (JSC::NativeErrorPrototype::finishCreation):
332         * runtime/NativeErrorPrototype.h:
333         (JSC::NativeErrorPrototype::create):
334         - updated to no longer need a JSGlobalObject argument.
335
336         * tests/es6/miscellaneous_built-in_prototypes_are_not_instances.js:
337         - updated to match the kangax version of this test.
338
339 2016-03-18  Benjamin Poulain  <bpoulain@apple.com>
340
341         [JSC] Limit DFG's Validate symbols to its compilation unit
342         https://bugs.webkit.org/show_bug.cgi?id=155670
343
344         Reviewed by Filip Pizlo.
345
346         * dfg/DFGValidate.cpp:
347
348 2016-03-18  Mark Lam  <mark.lam@apple.com>
349
350         ES6 spec requires that RegExpPrototype not be a RegExp object.
351         https://bugs.webkit.org/show_bug.cgi?id=155654
352
353         Reviewed by Filip Pizlo.
354
355         The ES6 spec states that RegExp.prototype should not be an instance of RegExp:
356         https://tc39.github.io/ecma262/#sec-properties-of-the-regexp-prototype-object
357
358         "The RegExp prototype object is an ordinary object. It is not a RegExp instance
359         and does not have a [[RegExpMatcher]] internal slot or any of the other internal
360         slots of RegExp instance objects."
361
362         This patch changes RegExpPrototype to conform to the above specifications.
363
364         * runtime/JSGlobalObject.cpp:
365         (JSC::JSGlobalObject::init):
366         * runtime/RegExpConstructor.cpp:
367         (JSC::RegExpConstructor::RegExpConstructor):
368         (JSC::RegExpConstructor::finishCreation):
369         * runtime/RegExpPrototype.cpp:
370         (JSC::RegExpPrototype::RegExpPrototype):
371         (JSC::RegExpPrototype::finishCreation):
372         (JSC::RegExpPrototype::getOwnPropertySlot):
373         (JSC::RegExpPrototype::visitChildren):
374         (JSC::regExpProtoFuncTest):
375         * runtime/RegExpPrototype.h:
376         (JSC::RegExpPrototype::create):
377         (JSC::RegExpPrototype::createStructure):
378         (JSC::RegExpPrototype::emptyRegExp):
379
380         * tests/es6.yaml:
381         - This patch makes the es6/miscellaneous_built-in_prototypes_are_not_instances.js
382           test now pass.  However, the kangax version of this test still fails because
383           it also checks Error objects (which will be fixed in a subsequent patch).
384
385         * tests/mozilla/ecma_2/shell.js:
386         (stringify):
387         (test):
388         (getFailedCases):
389         (err):
390         * tests/stress/static-getter-in-names.js:
391         (shouldBe):
392
393 2016-03-18  Keith Miller  <keith_miller@apple.com>
394
395         DataView should use an accessor for its length and buffer properties
396         https://bugs.webkit.org/show_bug.cgi?id=155625
397
398         Reviewed by Michael Saboff.
399
400         The DataView object should use an accessor on DataView.prototype for its
401         byteLength, byteOffset, and buffer properties. This patch also, moves the
402         buffer property off the TypedArray object itself and onto the prototype
403         along with the other accessors. Since the .buffer property is no longer on
404         the object, JSArrayBufferView no longer needs to intercept accesses to
405         properties. Finally, this patch also fixes the length property on all the
406         existing DataView.prototype functions.
407
408         * runtime/JSArrayBufferView.cpp:
409         (JSC::JSArrayBufferView::getOwnPropertySlot): Deleted.
410         (JSC::JSArrayBufferView::put): Deleted.
411         (JSC::JSArrayBufferView::defineOwnProperty): Deleted.
412         (JSC::JSArrayBufferView::deleteProperty): Deleted.
413         (JSC::JSArrayBufferView::getOwnNonIndexPropertyNames): Deleted.
414         * runtime/JSArrayBufferView.h:
415         (JSC::JSArrayBufferView::jsBuffer):
416         * runtime/JSDataViewPrototype.cpp:
417         (JSC::dataViewProtoGetterBuffer):
418         (JSC::dataViewProtoGetterByteLength):
419         (JSC::dataViewProtoGetterByteOffset):
420         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
421         (JSC::genericTypedArrayViewProtoGetterFuncBuffer):
422         * runtime/JSTypedArrayViewPrototype.cpp:
423         (JSC::typedArrayViewProtoGetterFuncBuffer):
424         (JSC::JSTypedArrayViewPrototype::finishCreation):
425
426 2016-03-18  Csaba Osztrogonác  <ossy@webkit.org>
427
428         Unreviewed speculative cloop buildfix after r198364.
429
430         * bytecode/SuperSampler.cpp:
431
432 2016-03-17  Benjamin Poulain  <bpoulain@apple.com>
433
434         [JSC] Make CSE's ImpureData faster when dealing with large blocks
435         https://bugs.webkit.org/show_bug.cgi?id=155594
436
437         Reviewed by Filip Pizlo.
438
439         In some tests with large blocks, the time spent in DFG's LocalCSE
440         can be over 10% of the total compile time.
441         In those cases, LocalCSE is completely dominated by handling large
442         blocks.
443
444         This patch addresses the most obvious hot spots ImpureData's handling.
445
446         Initially, most of the time was going into HashTable::rehash().
447         The reason is the buckets are <HeapLocation, LazyNode> gigantic.
448         The hash table would easily get into several kilobytes and the CPU
449         was spending more time dealing with memory than anything.
450
451         To solve that, I moved the pairs lazily to the heap. The table itself
452         just contains the unique_ptr to those values. This makes the table
453         reasonably small and the alloc/dealloc are paid for by the fast rehash().
454
455         Once addImpure() was better, the next big bottleneck was clobber().
456         For each clobber(), we need to go over the entire map and test each value.
457         That loop was where most of the time was going.
458
459         Most calls to clobber() come from two kinds: SideState and Stack.
460
461         SideState is easy: it is never def'ed so we can always skip it.
462
463         Stack is disjoint from Heap too so we can also put it separately.
464
465         Splitting the map into 2 helped reduce the overhead. The maps are:
466         -Stack
467         -Heap
468
469         Having Stack alone was not enough for many blocks. In some cases,
470         you have a ton of SetLocal/GetLocal and having Stack separately
471         makes no difference.
472
473         To solve that, I split Stack in two: a map addressed by AbstractHeap
474         + unique HeapLocation and a fallback map for everything else.
475         Since most Stack are not TOP and are unique per AbstractHeap,
476         I get O(1) clobber in most cases.
477
478         I could achieve the same result with a custom hash structure.
479         I don't think it is worth the effort, in most cases, m_fallbackStackMap
480         has a size of zero or one.
481
482         This patch introduces a lot of coupling between CSE and AbstractHeap.
483         To reduce the risk of bugs, the old map is still maintained in debug
484         and each step checks that the results are the same as the new implementation.
485
486         A new validation step also verify the strong assumptions made by CSE:
487         -SideState and World are never def().
488         -We never write HEAP TOP, we only write specific heap location.
489
490         * dfg/DFGCSEPhase.cpp:
491         * dfg/DFGHeapLocation.h:
492         * dfg/DFGLazyNode.h:
493         (JSC::DFG::LazyNode::hash):
494
495 2016-03-17  Saam barati  <sbarati@apple.com>
496
497         Implement SmallPtrSet and integrate it into the Parser
498         https://bugs.webkit.org/show_bug.cgi?id=155552
499
500         Reviewed by Filip Pizlo.
501
502         Using SmallPtrSet instead of HashSet really helps speed
503         up the parser. What saves us most is not needing to always
504         malloc/free memory in the HashSet.
505
506         * parser/Parser.cpp:
507         (JSC::Parser<LexerType>::parseInner):
508         * parser/Parser.h:
509         (JSC::Scope::Scope):
510         (JSC::Scope::startSwitch):
511         (JSC::Scope::endSwitch):
512         (JSC::Scope::startLoop):
513         (JSC::Scope::hasDeclaredParameter):
514         (JSC::Scope::declareWrite):
515         (JSC::Scope::declareParameter):
516         (JSC::Scope::usedVariablesContains):
517         (JSC::Scope::useVariable):
518         (JSC::Scope::collectFreeVariables):
519         (JSC::Scope::getCapturedVars):
520         (JSC::Scope::isValidStrictMode):
521         (JSC::Scope::shadowsArguments):
522         (JSC::Scope::copyCapturedVariablesToVector):
523         (JSC::Scope::setIsModule):
524         (JSC::Parser::pushScope):
525         (JSC::Scope::getUsedVariables): Deleted.
526
527 2016-03-17  Brian Burg  <bburg@apple.com>
528
529         Web Inspector: protocol generator shouldn't generate enums for parameters with non-anonymous enum types
530         https://bugs.webkit.org/show_bug.cgi?id=155610
531         <rdar://problem/25229878>
532
533         Reviewed by Joseph Pecoraro.
534
535         If a command parameter has an anonymous enum type, the backend dispatcher generator
536         makes a C++ enum for the parameter. However, if the parameter references a named enum
537         type specified in a domain's 'type' section, then there's no need to generate an enum.
538
539         * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
540         (CppBackendDispatcherHeaderGenerator._generate_handler_declaration_for_command):
541         Add a missing check for the is_anonymous flag. Type references to named enums are resolved
542         to the underlying aliased EnumType instead of an AliasedType, so we have to check the flag.
543
544         Rebaseline tests.
545
546         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
547         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
548
549 2016-03-17  Filip Pizlo  <fpizlo@apple.com>
550
551         Replace all of the various non-working and non-compiling sampling profiler hacks with a single super hack
552         https://bugs.webkit.org/show_bug.cgi?id=155561
553
554         Reviewed by Saam Barati.
555
556         A VM needs some internal profiling hacks in addition to the profiler(s) that the user sees, because
557         you can squeeze out more fidelity if you're willing to make some kind of deal with the devil. Prior
558         to this change JSC had a bunch of these:
559
560         - CodeBlock sampling profiler
561         - Bytecode sampling profiler
562         - Sampling flags
563         - Sampling regions
564         - Some other stuff
565
566         I tried using these recently. They didn't even build. Initially I fixed that, but then I found that
567         these profilers had some serious bugs that made them report bogus results - like underreporting the
568         time spent in regions of code by more than 2x.
569
570         Part of the problem here is that a profiler loses fidelity as it gains power. The more general it
571         tries to be, the more code gets executed on the hot path for the profiler, which increasingly
572         perturbs the results. I believe that's the reason for the underreporting - code ran sufficiently
573         slower, and in a sufficiently different way when profiling, that the results were just wrong.
574
575         This change attacks this problem directly by replacing all of the diverse profiling hacks with just
576         one, which I call the SuperSampler. It consists of exactly one counter. When enabled, the sampler
577         will periodically print (via dataLog()) the percentage of samples that saw a non-zero count. Because
578         it's so simple, it gives better accuracy. This comes about in two ways:
579
580         - It runs at a lower rate. That's fine since it's only checking one flag. You don't need a high rate
581           for just one flag.
582         
583         - The fact that there is only *one* flag means that the user must choose a hypothesis about what is
584           slow. This turns the problem of profiling into a hypothesis testing problem, which is an inherently
585           less flaky kind of experiment to run.
586         
587         The SuperSampler is enabled with a runtime flag rather than a compile-time flag, so it's much less
588         likely to break. That also means that you can enable it without rebuilding the universe. The old
589         samplers all had ENABLE flags in Platform.h, which was rather unfortunate for compile times.
590
591         SuperSampler supports both JIT and C++ users. C++ users should use SuperSamplerScope. The default
592         idiom is to create one and pass "true" to it. You can disable a scope by passing "false" instead.
593         This patch puts a bunch of scopes in places I care about. I think it's probably OK if people check in
594         these deactivated scopes. That makes it convenient to retest things we've tested previously.
595
596         * CMakeLists.txt:
597         * JavaScriptCore.xcodeproj/project.pbxproj:
598         * bytecode/SamplingTool.cpp: Removed.
599         * bytecode/SamplingTool.h: Removed.
600         * bytecode/SuperSampler.cpp: Added.
601         (JSC::initializeSuperSampler):
602         (JSC::printSuperSamplerState):
603         * bytecode/SuperSampler.h: Added.
604         (JSC::SuperSamplerScope::SuperSamplerScope):
605         (JSC::SuperSamplerScope::~SuperSamplerScope):
606         * bytecompiler/BytecodeGenerator.cpp:
607         (JSC::BytecodeGenerator::generate):
608         * bytecompiler/NodesCodegen.cpp:
609         * dfg/DFGAbstractInterpreterInlines.h:
610         (JSC::DFG::AbstractInterpreter<AbstractStateType>::forAllValues):
611         (JSC::DFG::AbstractInterpreter<AbstractStateType>::clobberStructures):
612         * dfg/DFGArgumentsEliminationPhase.cpp:
613         (JSC::DFG::performArgumentsElimination):
614         * dfg/DFGBackwardsPropagationPhase.cpp:
615         (JSC::DFG::performBackwardsPropagation):
616         * dfg/DFGByteCodeParser.cpp:
617         (JSC::DFG::parse):
618         * dfg/DFGCFAPhase.cpp:
619         (JSC::DFG::performCFA):
620         * dfg/DFGCFGSimplificationPhase.cpp:
621         (JSC::DFG::performCFGSimplification):
622         * dfg/DFGCPSRethreadingPhase.cpp:
623         (JSC::DFG::CPSRethreadingPhase::freeUnnecessaryNodes):
624         (JSC::DFG::CPSRethreadingPhase::canonicalizeLocalsInBlocks):
625         (JSC::DFG::CPSRethreadingPhase::propagatePhis):
626         (JSC::DFG::performCPSRethreading):
627         * dfg/DFGCSEPhase.cpp:
628         (JSC::DFG::performLocalCSE):
629         (JSC::DFG::performGlobalCSE):
630         * dfg/DFGCleanUpPhase.cpp:
631         (JSC::DFG::performCleanUp):
632         * dfg/DFGConstantFoldingPhase.cpp:
633         (JSC::DFG::performConstantFolding):
634         * dfg/DFGConstantHoistingPhase.cpp:
635         (JSC::DFG::performConstantHoisting):
636         * dfg/DFGCriticalEdgeBreakingPhase.cpp:
637         (JSC::DFG::performCriticalEdgeBreaking):
638         * dfg/DFGDCEPhase.cpp:
639         (JSC::DFG::performDCE):
640         * dfg/DFGDriver.cpp:
641         (JSC::DFG::compileImpl):
642         * dfg/DFGFixupPhase.cpp:
643         (JSC::DFG::performFixup):
644         * dfg/DFGGraph.cpp:
645         (JSC::DFG::Graph::dethread):
646         * dfg/DFGIntegerCheckCombiningPhase.cpp:
647         (JSC::DFG::performIntegerCheckCombining):
648         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
649         (JSC::DFG::performIntegerRangeOptimization):
650         * dfg/DFGInvalidationPointInjectionPhase.cpp:
651         (JSC::DFG::performInvalidationPointInjection):
652         * dfg/DFGJITCompiler.cpp:
653         (JSC::DFG::JITCompiler::compile):
654         (JSC::DFG::JITCompiler::compileFunction):
655         * dfg/DFGLICMPhase.cpp:
656         (JSC::DFG::performLICM):
657         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
658         (JSC::DFG::performLiveCatchVariablePreservationPhase):
659         * dfg/DFGLivenessAnalysisPhase.cpp:
660         (JSC::DFG::performLivenessAnalysis):
661         * dfg/DFGLoopPreHeaderCreationPhase.cpp:
662         (JSC::DFG::performLoopPreHeaderCreation):
663         * dfg/DFGMaximalFlushInsertionPhase.cpp:
664         (JSC::DFG::performMaximalFlushInsertion):
665         * dfg/DFGMovHintRemovalPhase.cpp:
666         (JSC::DFG::performMovHintRemoval):
667         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
668         (JSC::DFG::performOSRAvailabilityAnalysis):
669         * dfg/DFGOSREntrypointCreationPhase.cpp:
670         (JSC::DFG::performOSREntrypointCreation):
671         * dfg/DFGOSRExitCompiler.cpp:
672         * dfg/DFGObjectAllocationSinkingPhase.cpp:
673         (JSC::DFG::performObjectAllocationSinking):
674         * dfg/DFGOperations.cpp:
675         * dfg/DFGPhantomInsertionPhase.cpp:
676         (JSC::DFG::performPhantomInsertion):
677         * dfg/DFGPlan.cpp:
678         (JSC::DFG::Plan::compileInThread):
679         * dfg/DFGPredictionInjectionPhase.cpp:
680         (JSC::DFG::performPredictionInjection):
681         * dfg/DFGPredictionPropagationPhase.cpp:
682         (JSC::DFG::performPredictionPropagation):
683         * dfg/DFGPutStackSinkingPhase.cpp:
684         (JSC::DFG::performPutStackSinking):
685         * dfg/DFGSSAConversionPhase.cpp:
686         (JSC::DFG::performSSAConversion):
687         * dfg/DFGSSALoweringPhase.cpp:
688         (JSC::DFG::performSSALowering):
689         * dfg/DFGSpeculativeJIT64.cpp:
690         (JSC::DFG::SpeculativeJIT::compile):
691         * dfg/DFGStackLayoutPhase.cpp:
692         (JSC::DFG::performStackLayout):
693         * dfg/DFGStaticExecutionCountEstimationPhase.cpp:
694         (JSC::DFG::performStaticExecutionCountEstimation):
695         * dfg/DFGStoreBarrierInsertionPhase.cpp:
696         (JSC::DFG::performFastStoreBarrierInsertion):
697         (JSC::DFG::performGlobalStoreBarrierInsertion):
698         * dfg/DFGStrengthReductionPhase.cpp:
699         (JSC::DFG::performStrengthReduction):
700         * dfg/DFGStructureAbstractValue.cpp:
701         (JSC::DFG::StructureAbstractValue::assertIsRegistered):
702         (JSC::DFG::StructureAbstractValue::clobber):
703         (JSC::DFG::StructureAbstractValue::observeTransition):
704         (JSC::DFG::StructureAbstractValue::observeTransitions):
705         (JSC::DFG::StructureAbstractValue::add):
706         (JSC::DFG::StructureAbstractValue::merge):
707         (JSC::DFG::StructureAbstractValue::mergeSlow):
708         (JSC::DFG::StructureAbstractValue::mergeNotTop):
709         (JSC::DFG::StructureAbstractValue::filter):
710         (JSC::DFG::StructureAbstractValue::filterSlow):
711         (JSC::DFG::StructureAbstractValue::contains):
712         (JSC::DFG::StructureAbstractValue::isSubsetOf):
713         (JSC::DFG::StructureAbstractValue::isSupersetOf):
714         (JSC::DFG::StructureAbstractValue::overlaps):
715         (JSC::DFG::StructureAbstractValue::equalsSlow):
716         * dfg/DFGStructureRegistrationPhase.cpp:
717         (JSC::DFG::performStructureRegistration):
718         * dfg/DFGTierUpCheckInjectionPhase.cpp:
719         (JSC::DFG::performTierUpCheckInjection):
720         * dfg/DFGTypeCheckHoistingPhase.cpp:
721         (JSC::DFG::performTypeCheckHoisting):
722         * dfg/DFGUnificationPhase.cpp:
723         (JSC::DFG::performUnification):
724         * dfg/DFGVarargsForwardingPhase.cpp:
725         (JSC::DFG::performVarargsForwarding):
726         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
727         (JSC::DFG::performVirtualRegisterAllocation):
728         * dfg/DFGWatchpointCollectionPhase.cpp:
729         (JSC::DFG::performWatchpointCollection):
730         * dynbench.cpp:
731         * ftl/FTLLowerDFGToB3.cpp:
732         (JSC::FTL::DFG::LowerDFGToB3::compileRegExpExec):
733         (JSC::FTL::DFG::LowerDFGToB3::compileRegExpTest):
734         (JSC::FTL::DFG::LowerDFGToB3::compileStringReplace):
735         (JSC::FTL::DFG::LowerDFGToB3::compileGetRegExpObjectLastIndex):
736         * ftl/FTLOSRExitCompiler.cpp:
737         (JSC::FTL::compileFTLOSRExit):
738         * ftl/FTLOutput.cpp:
739         (JSC::FTL::Output::store):
740         (JSC::FTL::Output::absolute):
741         (JSC::FTL::Output::incrementSuperSamplerCount):
742         (JSC::FTL::Output::decrementSuperSamplerCount):
743         * ftl/FTLOutput.h:
744         (JSC::FTL::Output::baseIndex):
745         (JSC::FTL::Output::load8SignExt32):
746         (JSC::FTL::Output::load8ZeroExt32):
747         (JSC::FTL::Output::anchor):
748         (JSC::FTL::Output::absolute): Deleted.
749         * heap/Heap.cpp:
750         (JSC::Heap::markRoots):
751         (JSC::Heap::collectAndSweep):
752         (JSC::Heap::collectImpl):
753         (JSC::Heap::zombifyDeadObjects):
754         * heap/MarkedBlock.cpp:
755         (JSC::MarkedBlock::specializedSweep):
756         * interpreter/Interpreter.cpp:
757         (JSC::setupVarargsFrameAndSetThis):
758         (JSC::Interpreter::Interpreter):
759         (JSC::Interpreter::initialize):
760         (JSC::checkedReturn):
761         (JSC::Interpreter::execute):
762         (JSC::Interpreter::executeCall):
763         (JSC::Interpreter::executeConstruct):
764         (JSC::Interpreter::debug):
765         (JSC::SamplingScope::SamplingScope): Deleted.
766         (JSC::SamplingScope::~SamplingScope): Deleted.
767         (JSC::Interpreter::enableSampler): Deleted.
768         (JSC::Interpreter::dumpSampleData): Deleted.
769         (JSC::Interpreter::startSampling): Deleted.
770         (JSC::Interpreter::stopSampling): Deleted.
771         * interpreter/Interpreter.h:
772         (JSC::Interpreter::isCallBytecode):
773         (JSC::Interpreter::sampler): Deleted.
774         * jit/AssemblyHelpers.cpp:
775         (JSC::AssemblyHelpers::branchIfNotFastTypedArray):
776         (JSC::AssemblyHelpers::incrementSuperSamplerCount):
777         (JSC::AssemblyHelpers::decrementSuperSamplerCount):
778         (JSC::AssemblyHelpers::purifyNaN):
779         * jit/AssemblyHelpers.h:
780         * jit/JIT.cpp:
781         * jit/JIT.h:
782         * jit/JITArithmetic.cpp:
783         * jit/JITArithmetic32_64.cpp:
784         * jit/JITCall.cpp:
785         * jit/JITCall32_64.cpp:
786         * jit/JITOperations.cpp:
787         * jit/JITPropertyAccess.cpp:
788         * jit/JITPropertyAccess32_64.cpp:
789         * jsc.cpp:
790         (runWithScripts):
791         (jscmain):
792         * parser/Nodes.cpp:
793         * parser/Parser.h:
794         (JSC::parse):
795         * runtime/Executable.h:
796         * runtime/InitializeThreading.cpp:
797         (JSC::initializeThreading):
798         * runtime/Options.h:
799         * runtime/RegExpCachedResult.h:
800         * runtime/RegExpMatchesArray.h:
801         (JSC::createRegExpMatchesArray):
802         * runtime/StringPrototype.cpp:
803         (JSC::removeUsingRegExpSearch):
804         (JSC::stringProtoFuncSubstring):
805         * runtime/VM.cpp:
806         (JSC::VM::resetDateCache):
807         (JSC::VM::whenIdle):
808         (JSC::VM::deleteAllCode):
809         (JSC::VM::addSourceProviderCache):
810         (JSC::VM::startSampling): Deleted.
811         (JSC::VM::stopSampling): Deleted.
812         (JSC::VM::dumpSampleData): Deleted.
813         * runtime/VM.h:
814         (JSC::VM::regExpCache):
815         * testRegExp.cpp:
816         (runFromFiles):
817         * yarr/YarrInterpreter.cpp:
818         (JSC::Yarr::interpret):
819
820 2016-03-17  Saam barati  <sbarati@apple.com>
821
822         [ES6] Make GetProperty(.) inside ArrayPrototype.cpp spec compatible.
823         https://bugs.webkit.org/show_bug.cgi?id=155575
824
825         Reviewed by Filip Pizlo and Mark Lam.
826
827         This patch makes various Array.prototype.(shift | unshift | splice)
828         spec compliant. Before, they were performing Get and HasProperty as one 
829         operation. Instead, they need to be performed as two distinct operations
830         when it would be observable.
831
832         * runtime/ArrayPrototype.cpp:
833         (JSC::getProperty):
834         * runtime/PropertySlot.h:
835         (JSC::PropertySlot::PropertySlot):
836         (JSC::PropertySlot::isCacheableValue):
837         (JSC::PropertySlot::isCacheableGetter):
838         (JSC::PropertySlot::isCacheableCustom):
839         (JSC::PropertySlot::setIsTaintedByProxy):
840         (JSC::PropertySlot::isTaintedByProxy):
841         (JSC::PropertySlot::internalMethodType):
842         (JSC::PropertySlot::getValue):
843         * runtime/ProxyObject.cpp:
844         (JSC::ProxyObject::getOwnPropertySlotCommon):
845         * tests/es6.yaml:
846         * tests/stress/proxy-array-prototype-methods.js: Added.
847         (assert):
848         (test):
849         (shallowEq):
850
851 2016-03-17  Mark Lam  <mark.lam@apple.com>
852
853         Make FunctionMode an enum class.
854         https://bugs.webkit.org/show_bug.cgi?id=155587
855
856         Reviewed by Saam Barati.
857
858         * bytecode/UnlinkedFunctionExecutable.cpp:
859         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
860         * parser/NodeConstructors.h:
861         (JSC::BaseFuncExprNode::BaseFuncExprNode):
862         (JSC::FuncExprNode::FuncExprNode):
863         (JSC::FuncDeclNode::FuncDeclNode):
864         (JSC::ArrowFuncExprNode::ArrowFuncExprNode):
865         (JSC::MethodDefinitionNode::MethodDefinitionNode):
866         * parser/ParserModes.h:
867         (JSC::functionNameIsInScope):
868
869 2016-03-17  Michael Saboff  <msaboff@apple.com>
870
871         [ES6] Getters and Setters should be prefixed appropriately
872         https://bugs.webkit.org/show_bug.cgi?id=155593
873
874         Reviewed by Mark Lam.
875
876         Changed the putDirectNativeIntrinsicGetter() to prepend "get " to the funtion name.
877
878         Updated places that had their own macro or hand constructed a getter function to use
879         the JSC_NATIVE_GETTER macro which will properly append "get ".
880
881         Prepended "get " and "set " to the __proto__ accessor created on the Object prototype.
882
883         When we create the Symbol.species getter, added an explicit function name of "get [Symbol.species]".
884
885         * inspector/JSInjectedScriptHostPrototype.cpp:
886         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
887         (Inspector::jsInjectedScriptHostPrototypeAttributeEvaluate):
888         * inspector/JSJavaScriptCallFramePrototype.cpp:
889         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
890         (Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluate):
891         * runtime/JSGlobalObject.cpp:
892         (JSC::JSGlobalObject::init):
893         * runtime/JSObject.cpp:
894         (JSC::JSObject::putDirectNativeIntrinsicGetter):
895         * runtime/MapPrototype.cpp:
896         (JSC::MapPrototype::finishCreation):
897         (JSC::MapPrototype::getOwnPropertySlot):
898         * runtime/SetPrototype.cpp:
899         (JSC::SetPrototype::finishCreation):
900         (JSC::SetPrototype::getOwnPropertySlot):
901         * tests/stress/accessors-get-set-prefix.js: Added.
902         (tryGetOwnPropertyDescriptorGetName):
903
904 2016-03-16  Mark Lam  <mark.lam@apple.com>
905
906         Method names should not appear in the lexical scope of the method's body.
907         https://bugs.webkit.org/show_bug.cgi?id=155568
908
909         Reviewed by Saam Barati.
910
911         Consider this scenario:
912
913             var f = "foo";
914             var result = ({
915                 f() {
916                     return f; // f should be the string "foo", not this method f.
917                 }
918             }).f();
919             result === "foo"; // Should be true.
920
921         The reason this is not current working is because the parser does not yet
922         distinguish between FunctionExpressions and MethodDefinitions.  The ES6 spec
923         explicitly distinguishes between the 2, and we should do the same.
924         
925         This patch changes all methods (and getters and setters which are also methods)
926         to have a FunctionMode of MethodDefinition (instead of FunctionExpression).
927         functionNameIsInScope() is responsible for determining whether a function's name
928         should be in its scope or not.  It already returns false for any function
929         whose FunctionMode is not FunctionExpression.  Giving methods the MethodDefinition
930         FunctionMode gets us the correct behavior ES6 expects.
931
932         * bytecode/UnlinkedFunctionExecutable.cpp:
933         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
934         * bytecode/UnlinkedFunctionExecutable.h:
935         * bytecompiler/BytecodeGenerator.cpp:
936         (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
937         (JSC::BytecodeGenerator::emitNewMethodDefinition):
938         * bytecompiler/BytecodeGenerator.h:
939         * bytecompiler/NodesCodegen.cpp:
940         (JSC::ArrowFuncExprNode::emitBytecode):
941         (JSC::MethodDefinitionNode::emitBytecode):
942         (JSC::YieldExprNode::emitBytecode):
943         * parser/ASTBuilder.h:
944         (JSC::ASTBuilder::createFunctionExpr):
945         (JSC::ASTBuilder::createMethodDefinition):
946         (JSC::ASTBuilder::createFunctionMetadata):
947         (JSC::ASTBuilder::createGetterOrSetterProperty):
948         (JSC::ASTBuilder::createArguments):
949         * parser/NodeConstructors.h:
950         (JSC::FunctionParameters::FunctionParameters):
951         (JSC::BaseFuncExprNode::BaseFuncExprNode):
952         (JSC::FuncExprNode::FuncExprNode):
953         (JSC::FuncDeclNode::FuncDeclNode):
954         (JSC::ArrowFuncExprNode::ArrowFuncExprNode):
955         (JSC::MethodDefinitionNode::MethodDefinitionNode):
956         (JSC::YieldExprNode::YieldExprNode):
957         * parser/Nodes.h:
958         (JSC::BaseFuncExprNode::metadata):
959         * parser/Parser.cpp:
960         (JSC::Parser<LexerType>::parseClass):
961         (JSC::Parser<LexerType>::parsePropertyMethod):
962         * parser/ParserModes.h:
963         * parser/SyntaxChecker.h:
964         (JSC::SyntaxChecker::createFunctionExpr):
965         (JSC::SyntaxChecker::createFunctionMetadata):
966         (JSC::SyntaxChecker::createArrowFunctionExpr):
967         (JSC::SyntaxChecker::createMethodDefinition):
968         (JSC::SyntaxChecker::setFunctionNameStart):
969         (JSC::SyntaxChecker::createArguments):
970         * tests/es6.yaml:
971
972 2016-03-17  Yusuke Suzuki  <utatane.tea@gmail.com>
973
974         REGRESSION(r197380): Build fails with new GCC and Clang
975         https://bugs.webkit.org/show_bug.cgi?id=155044
976
977         Reviewed by Michael Catanzaro.
978
979         In C++, std math functions ceil and floor are overloaded for double and float.
980         Without explicit cast or function pointer assignment, compilers cannot
981         determine which function address is used in the given context.
982
983         * b3/B3LowerMacrosAfterOptimizations.cpp:
984
985 2016-03-17  Skachkov Oleksandr  <gskachkov@gmail.com>
986
987         Invoking super()/super inside of the eval should not lead to SyntaxError
988         https://bugs.webkit.org/show_bug.cgi?id=153864
989
990         Reviewed by Saam Barati.
991
992         Added support of the invoking super/super() inside of the eval within class.
993         Also support cases when eval is invoked in constructor, class method directly 
994         or via arrow function. Access to the new.target in eval is not part of this patch
995         and will be implemented in https://bugs.webkit.org/show_bug.cgi?id=155545
996
997         * bytecompiler/BytecodeGenerator.cpp:
998         (JSC::BytecodeGenerator::BytecodeGenerator):
999         (JSC::BytecodeGenerator::emitLoadArrowFunctionLexicalEnvironment):
1000         (JSC::BytecodeGenerator::isThisUsedInInnerArrowFunction):
1001         (JSC::BytecodeGenerator::isNewTargetUsedInInnerArrowFunction):
1002         (JSC::BytecodeGenerator::isSuperUsedInInnerArrowFunction):
1003         (JSC::BytecodeGenerator::isSuperCallUsedInInnerArrowFunction):
1004         (JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope):
1005         * interpreter/Interpreter.cpp:
1006         (JSC::eval):
1007         * parser/Parser.cpp:
1008         (JSC::Parser<LexerType>::Parser):
1009         (JSC::Parser<LexerType>::parseFunctionInfo):
1010         (JSC::Parser<LexerType>::parseMemberExpression):
1011         * parser/Parser.h:
1012         (JSC::Scope::Scope):
1013         (JSC::Scope::isEvalContext):
1014         (JSC::Scope::setIsEvalContext):
1015         (JSC::parse):
1016         * runtime/CodeCache.cpp:
1017         (JSC::CodeCache::getGlobalCodeBlock):
1018         * tests/stress/arrowfunction-lexical-bind-supercall-4.js:
1019         * tests/stress/arrowfunction-lexical-bind-superproperty.js:
1020         * tests/stress/class-syntax-super-in-eval.js: Added.
1021         * tests/stress/generator-with-super.js:
1022
1023 2016-03-15  Filip Pizlo  <fpizlo@apple.com>
1024
1025         ASSERTION FAILED: !edge->isPhantomAllocation() in regress/script-tests/sink-huge-activation.js.ftl-eager in debug mode
1026         https://bugs.webkit.org/show_bug.cgi?id=153805
1027
1028         Reviewed by Mark Lam.
1029
1030         The object allocation sinking phase uses InferredValue::isStillValid() in the opposite
1031         way from most clients: it will do an *extra* optimization if it returns false. The
1032         phase will first compute sink candidates and then it will compute materialization
1033         points. If something is a sink candidate then it is not a materialization point. A
1034         NewFunction node may appear as not being a sink candidate during the first pass, so it's
1035         not added to the set of things that will turn into PhantomNewFunction. But on the second
1036         pass where we add materializations, we check isStillValid() again. Now this may become
1037         false, so that second pass thinks that NewFunction is a sink candidate (even though it's
1038         not in the sink candidates set) and so is not a materialization point.
1039
1040         This manifests as the NewFunction referring to a PhantomCreateActivation or whatever.
1041
1042         The solution is to have the phase cache results of calls to isStillValid(). It's OK if
1043         we just remember the result of the first call and assume that it's not a sink candidate.
1044         That's the worst that can happen.
1045
1046         No new tests since this is a super hard race and sink-huge-activation seemed to already
1047         be catching it.
1048
1049         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1050
1051 2016-03-16  Saam Barati  <sbarati@apple.com>
1052
1053         [ES6] Make Array.prototype.reverse spec compatible.
1054         https://bugs.webkit.org/show_bug.cgi?id=155528
1055
1056         Reviewed by Michael Saboff.
1057
1058         This patch make Array.prototype.reverse spec compatible.
1059         Before, we weren't performing a HasProperty of each index
1060         before performing a Get on that index.  We now do that on
1061         the slow path.
1062
1063         * runtime/ArrayPrototype.cpp:
1064         (JSC::arrayProtoFuncReverse):
1065         * tests/stress/array-reverse-proxy.js: Added.
1066         (assert):
1067         (test):
1068         (shallowCopy):
1069         (shallowEqual):
1070         (let.handler.get getSet):
1071         (test.let.handler.get getSet):
1072
1073 2016-03-16  Chris Dumez  <cdumez@apple.com>
1074
1075         Unreviewed, rolling out r198235, r198240, r198241, and
1076         r198252.
1077
1078         Causing crashes on ARM
1079
1080         Reverted changesets:
1081
1082         "Remove compile time define for SEPARATED_HEAP"
1083         https://bugs.webkit.org/show_bug.cgi?id=155508
1084         http://trac.webkit.org/changeset/198235
1085
1086         "Gardening: build fix after r198235."
1087         http://trac.webkit.org/changeset/198240
1088
1089         "Build fix."
1090         http://trac.webkit.org/changeset/198241
1091
1092         "Rename performJITMemcpy to something more inline with our
1093         normal webkit function names"
1094         https://bugs.webkit.org/show_bug.cgi?id=155525
1095         http://trac.webkit.org/changeset/198252
1096
1097 2016-03-16  Brian Burg <bburg@apple.com>
1098
1099         Unreviewed, rolling out r198257.
1100         https://bugs.webkit.org/show_bug.cgi?id=155553
1101
1102         This change is unnecessary, clients can instead compile the
1103         file with ARC enabled (Requested by brrian on #webkit).
1104
1105         Reverted changeset:
1106
1107         "REGRESSION(r198077): generated Objective-C protocol object
1108         getters leak their wrappers"
1109         https://bugs.webkit.org/show_bug.cgi?id=155523
1110         http://trac.webkit.org/changeset/198257
1111
1112 2016-03-16  Mark Lam  <mark.lam@apple.com>
1113
1114         Add support for setting Function.name from computed properties.
1115         https://bugs.webkit.org/show_bug.cgi?id=155437
1116
1117         Reviewed by Filip Pizlo.
1118
1119         In JS code, we can have initialization of computed properties with function and
1120         class objects e.g.
1121
1122             var o = {
1123                 [x]: function() {},
1124                 [y]: class {}
1125             }
1126
1127         The ES6 spec states that the function and class in the example above (being
1128         anonymous) should take on the value of x and y respectively as their names:
1129
1130             o[x].name; // should be the "stringified" value of x.
1131             o[y].name; // should be the "stringified" value of y.
1132
1133         To achieve this, we will now inject an op_set_function_name bytecode at property
1134         initialization sites if:
1135
1136         1. the property assigned value is a function or class, and
1137         2. the function and class is anonymous, and
1138         3. if property assigned value is a class, it doesn't have a static method
1139            that is statically named "name".
1140
1141         The op_set_function_name will result in JSFunction::setFunctionName() being
1142         called on the target function / class before it is assigned to the property.
1143         JSFunction::setFunctionName() will take care of:
1144
1145         1. computing the name to use from the value of the computed property name
1146            e.g. x and y in the example above.
1147
1148            If the computed property name is not a symbol, then the function / class name
1149            should be the toString() value of that computed property name.
1150
1151            If the computed property name is a symbol, then ...
1152            a. if the Symbol has a defined description (e.g. Symbol("foo")), then the
1153               function / class name should be "[<symbol description>]" e.g. "[foo]".
1154            b. if the Symbol has an undefined description (e.g. Symbol()), then the
1155               function / class name should be "".
1156
1157            Note: Symbol("") is not the same as Symbol().  The former has a defined
1158            descriptor "", and hence, yields a function / class name of "[]".  The latter
1159            yields a function / class name of "".
1160
1161         2. reifying the lazy name property with this function / class name.
1162
1163         op_set_function_name is named after the SetFunctionName internal function
1164         in the ES6 spec that performs the above operation.
1165
1166         It is behaviorally correct to use op_set_function_name at every property
1167         initialization site with computed property names.  However, we choose to not
1168         emit the op_set_function_name bytecode when we already know that it will do
1169         nothing i.e. when the target function / class is proven to already have a name or
1170         name property.  This is done as an optimization to avoid unnecessary calls to
1171         JSFunction::setFunctionName().
1172
1173         Note: we could further check if the class has a static method with a computed
1174         name that is a constant string "name" and elide op_set_function_name there too.
1175         However, we don't bother because this should be rare.  JSFunction::setFunctionName()
1176         will still do the right thing.
1177
1178         * bytecode/BytecodeList.json:
1179         * bytecode/BytecodeUseDef.h:
1180         (JSC::computeUsesForBytecodeOffset):
1181         (JSC::computeDefsForBytecodeOffset):
1182         * bytecode/CodeBlock.cpp:
1183         (JSC::CodeBlock::dumpBytecode):
1184         * bytecompiler/BytecodeGenerator.cpp:
1185         (JSC::BytecodeGenerator::emitNewFunction):
1186         (JSC::BytecodeGenerator::emitSetFunctionNameIfNeeded):
1187         (JSC::BytecodeGenerator::emitCall):
1188         * bytecompiler/BytecodeGenerator.h:
1189         * bytecompiler/NodesCodegen.cpp:
1190         (JSC::PropertyListNode::emitBytecode):
1191         (JSC::PropertyListNode::emitPutConstantProperty):
1192         * dfg/DFGAbstractInterpreterInlines.h:
1193         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1194         * dfg/DFGByteCodeParser.cpp:
1195         (JSC::DFG::ByteCodeParser::parseBlock):
1196         * dfg/DFGCapabilities.cpp:
1197         (JSC::DFG::capabilityLevel):
1198         * dfg/DFGClobberize.h:
1199         (JSC::DFG::clobberize):
1200         * dfg/DFGDoesGC.cpp:
1201         (JSC::DFG::doesGC):
1202         * dfg/DFGFixupPhase.cpp:
1203         (JSC::DFG::FixupPhase::fixupNode):
1204         * dfg/DFGNodeType.h:
1205         * dfg/DFGPredictionPropagationPhase.cpp:
1206         (JSC::DFG::PredictionPropagationPhase::propagate):
1207         * dfg/DFGSafeToExecute.h:
1208         (JSC::DFG::safeToExecute):
1209         * dfg/DFGSpeculativeJIT.cpp:
1210         (JSC::DFG::SpeculativeJIT::compileNewFunction):
1211         (JSC::DFG::SpeculativeJIT::compileSetFunctionName):
1212         (JSC::DFG::SpeculativeJIT::compileForwardVarargs):
1213         * dfg/DFGSpeculativeJIT.h:
1214         (JSC::DFG::SpeculativeJIT::callOperation):
1215         * dfg/DFGSpeculativeJIT32_64.cpp:
1216         (JSC::DFG::SpeculativeJIT::compile):
1217         * dfg/DFGSpeculativeJIT64.cpp:
1218         (JSC::DFG::SpeculativeJIT::compile):
1219         * dfg/DFGStoreBarrierInsertionPhase.cpp:
1220         * ftl/FTLCapabilities.cpp:
1221         (JSC::FTL::canCompile):
1222         * ftl/FTLLowerDFGToB3.cpp:
1223         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1224         (JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
1225         (JSC::FTL::DFG::LowerDFGToB3::compileSetFunctionName):
1226         (JSC::FTL::DFG::LowerDFGToB3::compileStringReplace):
1227         * jit/JIT.cpp:
1228         (JSC::JIT::privateCompileMainPass):
1229         * jit/JIT.h:
1230         * jit/JITInlines.h:
1231         (JSC::JIT::callOperation):
1232         * jit/JITOpcodes.cpp:
1233         (JSC::JIT::emit_op_to_primitive):
1234         (JSC::JIT::emit_op_set_function_name):
1235         (JSC::JIT::emit_op_strcat):
1236         * jit/JITOpcodes32_64.cpp:
1237         (JSC::JIT::emitSlow_op_to_primitive):
1238         (JSC::JIT::emit_op_set_function_name):
1239         (JSC::JIT::emit_op_strcat):
1240         * jit/JITOperations.cpp:
1241         * jit/JITOperations.h:
1242         * llint/LLIntSlowPaths.cpp:
1243         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1244         (JSC::LLInt::handleHostCall):
1245         * llint/LLIntSlowPaths.h:
1246         * llint/LowLevelInterpreter.asm:
1247         * parser/Nodes.cpp:
1248         (JSC::FunctionNode::finishParsing):
1249         (JSC::PropertyListNode::hasStaticallyNamedProperty):
1250         (JSC::VariableEnvironmentNode::VariableEnvironmentNode):
1251         * parser/Nodes.h:
1252         * runtime/JSFunction.cpp:
1253         (JSC::getCalculatedDisplayName):
1254         (JSC::JSFunction::setFunctionName):
1255         (JSC::JSFunction::reifyLength):
1256         (JSC::JSFunction::reifyName):
1257         * runtime/JSFunction.h:
1258         * tests/es6.yaml:
1259         * tests/stress/computed-function-names.js: Added.
1260         (toKeyString):
1261         (toFuncName):
1262         (shouldBe):
1263         (return.propKey):
1264
1265 2016-03-16  Yusuke Suzuki  <utatane.tea@gmail.com>
1266
1267         [ES6] Reflect.set with receiver
1268         https://bugs.webkit.org/show_bug.cgi?id=155294
1269
1270         Reviewed by Saam Barati.
1271
1272         This patch introduces the receiver parameter support for Reflect.set.
1273         Reflect.set can alter the receiver with arbitrary values.
1274         Each property descriptor uses the receiver in [[Set]].
1275
1276         1) In the accessor descriptor case, the receiver is used as |this| value for setter calls.
1277         2) In the data descriptor case, the actual property will be set onto the receiver objects.
1278
1279         The current put operation does not support the receiver that is different from the base object.
1280         In particular, (2) case is not supported.
1281         The naive implementation adds one more [[GetOwnProperty]] for the receiver per [[Set]] (9.1.9.1-4-c [1]), and it is unacceptable.
1282         To keep the fast path efficiently, we fall back to the slow but generic implementation (ordinarySetSlow)
1283         only when the receiver is altered.
1284
1285         We need not to change any JIT part, because the JS code cannot alter the receiver without Reflect.set.
1286         The property accesses generated by the JIT code always have the receiver that is the same to the base object.
1287         ProxyObject can alter the receiver, but this situation has no problem because ProxyObject disables Inline Caching.
1288         NOTE: Generating Inline Caching for JSProxy (that is used for the Window proxy) is already disabled before this change.
1289
1290         [1]: https://tc39.github.io/ecma262/#sec-ordinaryset
1291
1292         * jsc.cpp:
1293         (functionCreateProxy):
1294         * runtime/GenericArgumentsInlines.h:
1295         (JSC::GenericArguments<Type>::put):
1296         * runtime/JSArray.cpp:
1297         (JSC::JSArray::put):
1298         * runtime/JSArrayBuffer.cpp:
1299         (JSC::JSArrayBuffer::put):
1300         * runtime/JSArrayBufferView.cpp:
1301         (JSC::JSArrayBufferView::put):
1302         * runtime/JSCJSValue.h:
1303         * runtime/JSCJSValueInlines.h:
1304         (JSC::isThisValueAltered):
1305         * runtime/JSDataView.cpp:
1306         (JSC::JSDataView::put):
1307         * runtime/JSFunction.cpp:
1308         (JSC::JSFunction::put):
1309         * runtime/JSGenericTypedArrayViewInlines.h:
1310         (JSC::JSGenericTypedArrayView<Adaptor>::put):
1311         * runtime/JSGlobalObject.cpp:
1312         (JSC::JSGlobalObject::put):
1313         * runtime/JSObject.cpp:
1314         (JSC::ordinarySetSlow):
1315         (JSC::JSObject::putInlineSlow):
1316         * runtime/JSObject.h:
1317         * runtime/JSObjectInlines.h:
1318         (JSC::JSObject::putInline):
1319         * runtime/JSProxy.h:
1320         (JSC::JSProxy::createStructure):
1321         * runtime/Lookup.h:
1322         (JSC::putEntry):
1323         * runtime/PropertySlot.h:
1324         * runtime/ProxyObject.cpp:
1325         (JSC::ProxyObject::put):
1326         * runtime/PutPropertySlot.h:
1327         (JSC::PutPropertySlot::PutPropertySlot):
1328         (JSC::PutPropertySlot::isCacheablePut):
1329         (JSC::PutPropertySlot::isCacheableSetter):
1330         (JSC::PutPropertySlot::isCacheableCustom):
1331         (JSC::PutPropertySlot::isCustomAccessor):
1332         (JSC::PutPropertySlot::disableCaching):
1333         (JSC::PutPropertySlot::isCacheable):
1334         * runtime/ReflectObject.cpp:
1335         (JSC::reflectObjectSet):
1336         * runtime/RegExpObject.cpp:
1337         (JSC::RegExpObject::put):
1338         (JSC::reject): Deleted.
1339         * runtime/StringObject.cpp:
1340         (JSC::StringObject::put):
1341         * tests/es6.yaml:
1342         * tests/stress/ordinary-set-exceptions.js: Added.
1343         (shouldBe):
1344         (shouldThrow):
1345         (shouldThrow.set get var):
1346         * tests/stress/proxy-set.js:
1347         * tests/stress/reflect-set-proxy-set.js: Copied from Source/JavaScriptCore/tests/stress/proxy-set.js.
1348         (shouldBe):
1349         (unreachable):
1350         (assert):
1351         (throw.new.Error.let.handler.set 45):
1352         (throw.new.Error):
1353         (let.target.set x):
1354         (let.target.get x):
1355         (set let):
1356         * tests/stress/reflect-set-receiver-proxy-set.js: Added.
1357         (shouldBe):
1358         (unreachable):
1359         (assert):
1360         (let.handler.set 45):
1361         (catch):
1362         (let.target.set x):
1363         (let.target.get x):
1364         (set let):
1365         * tests/stress/reflect-set-with-global-proxy.js: Added.
1366         (shouldBe):
1367         (unreachable):
1368         (get shouldBe):
1369         (set shouldBe):
1370         (set test1):
1371         (set test2):
1372         (set test3):
1373         * tests/stress/reflect-set.js:
1374         (shouldThrow):
1375         (unreachable):
1376         (get shouldBe):
1377         (set shouldBe):
1378         (receiverTestIndexed):
1379         (set get Uint8Array):
1380         (receiverCase): Deleted.
1381         (proxyCase): Deleted.
1382         (stringObjectCase.set get shouldBe): Deleted.
1383         (regExpLastIndex): Deleted.
1384
1385 2016-03-15  Benjamin Poulain  <bpoulain@apple.com>
1386
1387         [JSC] Remove hint from SlowCaseEntry
1388         https://bugs.webkit.org/show_bug.cgi?id=155530
1389
1390         Reviewed by Alex Christensen.
1391
1392         * jit/JIT.h:
1393         (JSC::SlowCaseEntry::SlowCaseEntry):
1394
1395 2016-03-15  Brian Burg  <bburg@apple.com>
1396
1397         REGRESSION(r198077): generated Objective-C protocol object getters leak their wrappers
1398         https://bugs.webkit.org/show_bug.cgi?id=155523
1399         <rdar://problem/25181764>
1400
1401         Reviewed by Joseph Pecoraro.
1402
1403         Since the code may not be compiled with ARC, autorelease the returned wrapper.
1404
1405         * inspector/scripts/codegen/objc_generator.py:
1406         (ObjCGenerator.protocol_to_objc_expression_for_member):
1407         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
1408         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
1409
1410 2016-03-15  Benjamin Poulain  <bpoulain@apple.com>
1411
1412         [JSC] Help clang generate better code on arrayProtoFuncToString()
1413         https://bugs.webkit.org/show_bug.cgi?id=155512
1414
1415         Reviewed by Mark Lam.
1416
1417         3d-raytrace hits Array.toString() hard with small arrays.
1418         Half of the time is going into overhead around the StringJoiner.
1419         This patch makes the function shorter and the layout better.
1420
1421         * runtime/ArrayPrototype.cpp:
1422         (JSC::arrayProtoFuncToString):
1423         Add "UNLIKELY" on rare cases. Clang pushes that code to the tail.
1424
1425         Factor the code of jsMakeNontrivialString() so that the operation
1426         is not duplicated in the function.
1427
1428         * runtime/JSStringBuilder.h:
1429         (JSC::jsMakeNontrivialString):
1430         jsNontrivialString() supports r-value reference.
1431         Move the result string into jsNontrivialString(), this removes
1432         the deref+destructor from the function.
1433
1434         * runtime/JSStringJoiner.cpp:
1435         (JSC::JSStringJoiner::~JSStringJoiner):
1436         The destructor is pretty large. No point in inlining it.
1437
1438         (JSC::joinStrings):
1439         * runtime/JSStringJoiner.h:
1440         (JSC::JSStringJoiner::JSStringJoiner):
1441         (JSC::JSStringJoiner::append):
1442         The calls were duplicated. That's unnecessary.
1443
1444         * runtime/NumericStrings.h:
1445         (JSC::NumericStrings::add):
1446         Return a reference in all cases.
1447         This removes a deref+destructor.
1448
1449 2016-03-15  Joseph Pecoraro  <pecoraro@apple.com>
1450
1451         Remove stale ArrayPrototype declarations
1452         https://bugs.webkit.org/show_bug.cgi?id=155520
1453
1454         Reviewed by Mark Lam.
1455
1456         * runtime/ArrayPrototype.cpp:
1457         The implementations went away when the methods were moved to builtins
1458         but the declarations were left behind.
1459
1460 2016-03-15  Oliver Hunt  <oliver@apple.com>
1461
1462         Rename performJITMemcpy to something more inline with our normal webkit function names
1463         https://bugs.webkit.org/show_bug.cgi?id=155525
1464
1465         Reviewed by Saam Barati.
1466
1467         Simple bulk search/replace with a better name.
1468
1469         * assembler/ARM64Assembler.h:
1470         (JSC::ARM64Assembler::fillNops):
1471         (JSC::ARM64Assembler::replaceWithJump):
1472         (JSC::ARM64Assembler::replaceWithLoad):
1473         (JSC::ARM64Assembler::replaceWithAddressComputation):
1474         (JSC::ARM64Assembler::setPointer):
1475         (JSC::ARM64Assembler::repatchInt32):
1476         (JSC::ARM64Assembler::repatchCompact):
1477         (JSC::ARM64Assembler::linkJumpOrCall):
1478         (JSC::ARM64Assembler::linkCompareAndBranch):
1479         (JSC::ARM64Assembler::linkConditionalBranch):
1480         (JSC::ARM64Assembler::linkTestAndBranch):
1481         * assembler/LinkBuffer.cpp:
1482         (JSC::LinkBuffer::copyCompactAndLinkCode):
1483         * jit/ExecutableAllocator.h:
1484         (JSC::writeToExecutableRegion):
1485         (JSC::performJITMemcpy): Deleted.
1486
1487 2016-03-15  Oliver Hunt  <oliver@apple.com>
1488
1489         Build fix.
1490
1491         * jit/ExecutableAllocatorFixedVMPool.cpp:
1492
1493 2016-03-15  Mark Lam  <mark.lam@apple.com>
1494
1495         Gardening: build fix after r198235.
1496
1497         Not Reviewed.
1498
1499         * jit/ExecutableAllocatorFixedVMPool.cpp:
1500         (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
1501
1502 2016-03-15  Oliver Hunt  <oliver@apple.com>
1503
1504         Remove compile time define for SEPARATED_HEAP
1505         https://bugs.webkit.org/show_bug.cgi?id=155508
1506
1507         Reviewed by Mark Lam.
1508
1509         This removes the compile time define for the SEPARATED_HEAP
1510         feature, and moves to a default-off runtime preference.
1511
1512         This happily also removes the need for world rebuilds while
1513         bringing it up on different platforms.
1514
1515         * Configurations/FeatureDefines.xcconfig:
1516         * assembler/LinkBuffer.cpp:
1517         (JSC::LinkBuffer::copyCompactAndLinkCode):
1518         * jit/ExecutableAllocator.h:
1519         (JSC::performJITMemcpy):
1520         * jit/ExecutableAllocatorFixedVMPool.cpp:
1521         (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
1522         (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
1523         (JSC::FixedVMPoolExecutableAllocator::genericWriteToJITRegion):
1524         (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): Deleted.
1525         * runtime/Options.cpp:
1526         (JSC::recomputeDependentOptions):
1527         * runtime/Options.h:
1528
1529 2016-03-15  Commit Queue  <commit-queue@webkit.org>
1530
1531         Unreviewed, rolling out r198148.
1532         https://bugs.webkit.org/show_bug.cgi?id=155518
1533
1534         "Lets do this patch at a later time" (Requested by saamyjoon
1535         on #webkit).
1536
1537         Reverted changeset:
1538
1539         "[ES6] Disallow var assignments in for-in loops"
1540         https://bugs.webkit.org/show_bug.cgi?id=155451
1541         http://trac.webkit.org/changeset/198148
1542
1543 2016-03-15  Joseph Pecoraro  <pecoraro@apple.com>
1544
1545         REGRESSION: ASSERTION FAILED: !m_lastActiveBlock on js/function-apply.html
1546         https://bugs.webkit.org/show_bug.cgi?id=155411
1547         <rdar://problem/25134537>
1548
1549         Reviewed by Mark Lam.
1550
1551         * heap/Heap.cpp:
1552         (JSC::Heap::collectImpl):
1553         (JSC::Heap::didFinishCollection):
1554         During collection allocators are stop/reset. The HeapProfiler tasks
1555         were using HeapIterationScope (to satisfy MarkedSpace forEachCell API
1556         contracts) which was doing its own stop/resume of allocators. Doing a
1557         stop/resume in between the normal stop/reset of collection is unexpected.
1558
1559         Move this to didFinishCollection, alongside other heap iterations
1560         like zombies and immortal objects. Putting this after those tasks
1561         also means the heap snapshots will respect the zombies/immortal options
1562         when deciding if the cell is alive or not.
1563
1564 2016-03-15  Saam Barati  <sbarati@apple.com>
1565
1566         We should have different JSTypes for JSGlobalLexicalEnvironment and JSLexicalEnvironment and JSModuleEnvironment
1567         https://bugs.webkit.org/show_bug.cgi?id=152406
1568
1569         Reviewed by Mark Lam.
1570
1571         This makes testing for a JSGlobalLexicalEnvironment faster
1572         because we can just check the Cell's type instead of using
1573         jsDynamicCast. I also changed code that does jsDynamicCast<JSGlobalObject*>
1574         instead of isGlobalObject().
1575
1576         * interpreter/Interpreter.cpp:
1577         (JSC::Interpreter::execute):
1578         * jit/JITOperations.cpp:
1579         * llint/LLIntSlowPaths.cpp:
1580         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1581         * runtime/CommonSlowPaths.cpp:
1582         (JSC::SLOW_PATH_DECL):
1583         * runtime/CommonSlowPaths.h:
1584         (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
1585         (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
1586         * runtime/JSGlobalLexicalEnvironment.h:
1587         (JSC::JSGlobalLexicalEnvironment::createStructure):
1588         * runtime/JSLexicalEnvironment.h:
1589         (JSC::JSLexicalEnvironment::createStructure):
1590         (JSC::JSLexicalEnvironment::JSLexicalEnvironment):
1591         * runtime/JSModuleEnvironment.h:
1592         (JSC::JSModuleEnvironment::createStructure):
1593         (JSC::JSModuleEnvironment::offsetOfModuleRecord):
1594         * runtime/JSObject.h:
1595         (JSC::JSObject::isGlobalObject):
1596         (JSC::JSObject::isJSLexicalEnvironment):
1597         (JSC::JSObject::isGlobalLexicalEnvironment):
1598         (JSC::JSObject::isErrorInstance):
1599         * runtime/JSScope.cpp:
1600         (JSC::abstractAccess):
1601         (JSC::isUnscopable):
1602         (JSC::JSScope::resolve):
1603         (JSC::JSScope::collectVariablesUnderTDZ):
1604         (JSC::JSScope::isVarScope):
1605         (JSC::JSScope::isLexicalScope):
1606         (JSC::JSScope::isModuleScope):
1607         (JSC::JSScope::isCatchScope):
1608         (JSC::JSScope::isFunctionNameScopeObject):
1609         (JSC::JSScope::isNestedLexicalScope):
1610         (JSC::JSScope::constantScopeForCodeBlock):
1611         (JSC::isScopeType): Deleted.
1612         (JSC::JSScope::isGlobalLexicalEnvironment): Deleted.
1613         * runtime/JSScope.h:
1614         * runtime/JSType.h:
1615
1616 2016-03-15  Filip Pizlo  <fpizlo@apple.com>
1617
1618         Remove the Baker barrier from JSC
1619         https://bugs.webkit.org/show_bug.cgi?id=155479
1620
1621         Reviewed by Saam Barati.
1622
1623         It's been a while since I added a Baker barrier, but I never followed it up with an actual
1624         concurrent GC. While thinking about the GC, I became convinced that the right path forward
1625         is to do a non-copying concurrent GC. That is, remove the copied space and just use the
1626         marked space. The downside of using marked space cannot be more than the overhead of the
1627         Baker barrier, so concurrent non-copying GC is definitely better than copying
1628         non-concurrent GC. I also suspect that just plain non-copying non-concurrent GC is going to
1629         be fine also, so the path forward will probably be to first just remove CopiedSpace.
1630
1631         Anyway, for now this patch just removes the Baker barrier. It was a cute implementation but
1632         it just cost performance and I don't think we'll ever use it.
1633
1634         * CMakeLists.txt:
1635         * JavaScriptCore.xcodeproj/project.pbxproj:
1636         * bytecode/PolymorphicAccess.cpp:
1637         (JSC::AccessCase::generate):
1638         * dfg/DFGAbstractInterpreterInlines.h:
1639         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1640         * dfg/DFGArgumentsEliminationPhase.cpp:
1641         * dfg/DFGClobberize.h:
1642         (JSC::DFG::clobberize):
1643         * dfg/DFGCopyBarrierOptimizationPhase.cpp: Removed.
1644         * dfg/DFGCopyBarrierOptimizationPhase.h: Removed.
1645         * dfg/DFGDoesGC.cpp:
1646         (JSC::DFG::doesGC):
1647         * dfg/DFGFixupPhase.cpp:
1648         (JSC::DFG::FixupPhase::fixupNode):
1649         * dfg/DFGHeapLocation.cpp:
1650         (WTF::printInternal):
1651         * dfg/DFGHeapLocation.h:
1652         * dfg/DFGNodeType.h:
1653         * dfg/DFGOperations.cpp:
1654         * dfg/DFGOperations.h:
1655         * dfg/DFGPlan.cpp:
1656         (JSC::DFG::Plan::compileInThreadImpl):
1657         * dfg/DFGPredictionPropagationPhase.cpp:
1658         (JSC::DFG::PredictionPropagationPhase::propagate):
1659         * dfg/DFGSafeToExecute.h:
1660         (JSC::DFG::safeToExecute):
1661         * dfg/DFGSpeculativeJIT.cpp:
1662         (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
1663         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
1664         (JSC::DFG::SpeculativeJIT::compileGetButterfly):
1665         * dfg/DFGSpeculativeJIT32_64.cpp:
1666         (JSC::DFG::SpeculativeJIT::compile):
1667         * dfg/DFGSpeculativeJIT64.cpp:
1668         (JSC::DFG::SpeculativeJIT::compile):
1669         * dfg/DFGTypeCheckHoistingPhase.cpp:
1670         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
1671         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
1672         * ftl/FTLCapabilities.cpp:
1673         (JSC::FTL::canCompile):
1674         * ftl/FTLLowerDFGToB3.cpp:
1675         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1676         (JSC::FTL::DFG::LowerDFGToB3::compileGetButterfly):
1677         (JSC::FTL::DFG::LowerDFGToB3::compileConstantStoragePointer):
1678         (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
1679         (JSC::FTL::DFG::LowerDFGToB3::compileCheckArray):
1680         (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
1681         (JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset):
1682         (JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
1683         (JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname):
1684         (JSC::FTL::DFG::LowerDFGToB3::storageForTransition):
1685         (JSC::FTL::DFG::LowerDFGToB3::getById):
1686         (JSC::FTL::DFG::LowerDFGToB3::isFastTypedArray):
1687         (JSC::FTL::DFG::LowerDFGToB3::compileGetButterflyReadOnly): Deleted.
1688         (JSC::FTL::DFG::LowerDFGToB3::loadButterflyWithBarrier): Deleted.
1689         (JSC::FTL::DFG::LowerDFGToB3::loadVectorWithBarrier): Deleted.
1690         (JSC::FTL::DFG::LowerDFGToB3::copyBarrier): Deleted.
1691         (JSC::FTL::DFG::LowerDFGToB3::isInToSpace): Deleted.
1692         (JSC::FTL::DFG::LowerDFGToB3::loadButterflyReadOnly): Deleted.
1693         (JSC::FTL::DFG::LowerDFGToB3::loadVectorReadOnly): Deleted.
1694         (JSC::FTL::DFG::LowerDFGToB3::removeSpaceBits): Deleted.
1695         * heap/CopyBarrier.h:
1696         (JSC::CopyBarrierBase::CopyBarrierBase):
1697         (JSC::CopyBarrierBase::operator bool):
1698         (JSC::CopyBarrierBase::get):
1699         (JSC::CopyBarrierBase::clear):
1700         (JSC::CopyBarrierBase::setWithoutBarrier):
1701         (JSC::CopyBarrier::CopyBarrier):
1702         (JSC::CopyBarrier::get):
1703         (JSC::CopyBarrier::set):
1704         (JSC::CopyBarrier::setWithoutBarrier):
1705         (JSC::CopyBarrierBase::operator!): Deleted.
1706         (JSC::CopyBarrierBase::getWithoutBarrier): Deleted.
1707         (JSC::CopyBarrierBase::getPredicated): Deleted.
1708         (JSC::CopyBarrierBase::copyState): Deleted.
1709         (JSC::CopyBarrierBase::setCopyState): Deleted.
1710         (JSC::CopyBarrierBase::weakCASWithoutBarrier): Deleted.
1711         (JSC::CopyBarrier::getWithoutBarrier): Deleted.
1712         (JSC::CopyBarrier::getPredicated): Deleted.
1713         (JSC::CopyBarrier::weakCASWithoutBarrier): Deleted.
1714         * heap/Heap.cpp:
1715         (JSC::Heap::addToRememberedSet):
1716         (JSC::Heap::collectAndSweep):
1717         (JSC::Heap::copyBarrier): Deleted.
1718         * heap/Heap.h:
1719         (JSC::Heap::writeBarrierBuffer):
1720         * jit/AssemblyHelpers.cpp:
1721         (JSC::AssemblyHelpers::branchIfNotFastTypedArray):
1722         (JSC::AssemblyHelpers::purifyNaN):
1723         (JSC::AssemblyHelpers::loadTypedArrayVector): Deleted.
1724         * jit/AssemblyHelpers.h:
1725         (JSC::AssemblyHelpers::branchStructure):
1726         (JSC::AssemblyHelpers::addressForByteOffset):
1727         (JSC::AssemblyHelpers::branchIfToSpace): Deleted.
1728         (JSC::AssemblyHelpers::branchIfNotToSpace): Deleted.
1729         (JSC::AssemblyHelpers::removeSpaceBits): Deleted.
1730         * jit/JIT.cpp:
1731         (JSC::JIT::privateCompileMainPass):
1732         (JSC::JIT::privateCompile):
1733         * jit/JITOpcodes.cpp:
1734         (JSC::JIT::emitSlow_op_has_indexed_property):
1735         (JSC::JIT::emit_op_get_direct_pname):
1736         (JSC::JIT::emitSlow_op_get_direct_pname):
1737         * jit/JITOpcodes32_64.cpp:
1738         (JSC::JIT::emit_op_get_direct_pname):
1739         (JSC::JIT::emitSlow_op_get_direct_pname):
1740         * jit/JITPropertyAccess.cpp:
1741         (JSC::JIT::emitDoubleLoad):
1742         (JSC::JIT::emitContiguousLoad):
1743         (JSC::JIT::emitArrayStorageLoad):
1744         (JSC::JIT::emitSlow_op_get_by_val):
1745         (JSC::JIT::emitGenericContiguousPutByVal):
1746         (JSC::JIT::emitArrayStoragePutByVal):
1747         (JSC::JIT::emitSlow_op_put_by_val):
1748         (JSC::JIT::emit_op_get_from_scope):
1749         (JSC::JIT::emitSlow_op_get_from_scope):
1750         (JSC::JIT::emit_op_put_to_scope):
1751         (JSC::JIT::emitSlow_op_put_to_scope):
1752         (JSC::JIT::emitIntTypedArrayGetByVal):
1753         (JSC::JIT::emitFloatTypedArrayGetByVal):
1754         (JSC::JIT::emitIntTypedArrayPutByVal):
1755         (JSC::JIT::emitFloatTypedArrayPutByVal):
1756         * llint/LowLevelInterpreter.asm:
1757         * llint/LowLevelInterpreter64.asm:
1758         * runtime/DirectArguments.cpp:
1759         (JSC::DirectArguments::visitChildren):
1760         (JSC::DirectArguments::copyBackingStore):
1761         (JSC::DirectArguments::overrideArgument):
1762         (JSC::DirectArguments::copyToArguments):
1763         * runtime/DirectArguments.h:
1764         (JSC::DirectArguments::canAccessIndexQuickly):
1765         (JSC::DirectArguments::canAccessArgumentIndexQuicklyInDFG):
1766         * runtime/JSArray.cpp:
1767         (JSC::JSArray::setLength):
1768         (JSC::JSArray::pop):
1769         (JSC::JSArray::push):
1770         (JSC::JSArray::fastSlice):
1771         (JSC::JSArray::fastConcatWith):
1772         (JSC::JSArray::shiftCountWithArrayStorage):
1773         (JSC::JSArray::shiftCountWithAnyIndexingType):
1774         (JSC::JSArray::unshiftCountWithAnyIndexingType):
1775         (JSC::JSArray::fillArgList):
1776         (JSC::JSArray::copyToArguments):
1777         * runtime/JSArrayBufferView.cpp:
1778         (JSC::JSArrayBufferView::finalize):
1779         * runtime/JSArrayBufferView.h:
1780         (JSC::JSArrayBufferView::isNeutered):
1781         (JSC::JSArrayBufferView::vector):
1782         (JSC::JSArrayBufferView::length):
1783         * runtime/JSGenericTypedArrayViewInlines.h:
1784         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
1785         (JSC::JSGenericTypedArrayView<Adaptor>::copyBackingStore):
1786         * runtime/JSObject.cpp:
1787         (JSC::JSObject::visitChildren):
1788         (JSC::JSObject::copyBackingStore):
1789         (JSC::JSObject::heapSnapshot):
1790         (JSC::JSObject::getOwnPropertySlotByIndex):
1791         (JSC::JSObject::putByIndex):
1792         (JSC::JSObject::enterDictionaryIndexingMode):
1793         (JSC::JSObject::createInitialIndexedStorage):
1794         (JSC::JSObject::createArrayStorage):
1795         (JSC::JSObject::convertUndecidedToInt32):
1796         (JSC::JSObject::convertUndecidedToDouble):
1797         (JSC::JSObject::convertUndecidedToContiguous):
1798         (JSC::JSObject::constructConvertedArrayStorageWithoutCopyingElements):
1799         (JSC::JSObject::convertUndecidedToArrayStorage):
1800         (JSC::JSObject::convertInt32ToDouble):
1801         (JSC::JSObject::convertInt32ToContiguous):
1802         (JSC::JSObject::convertInt32ToArrayStorage):
1803         (JSC::JSObject::convertDoubleToContiguous):
1804         (JSC::JSObject::convertDoubleToArrayStorage):
1805         (JSC::JSObject::convertContiguousToArrayStorage):
1806         (JSC::JSObject::setIndexQuicklyToUndecided):
1807         (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode):
1808         (JSC::JSObject::deletePropertyByIndex):
1809         (JSC::JSObject::getOwnPropertyNames):
1810         (JSC::JSObject::putIndexedDescriptor):
1811         (JSC::JSObject::defineOwnIndexedProperty):
1812         (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
1813         (JSC::JSObject::putDirectIndexBeyondVectorLength):
1814         (JSC::JSObject::getNewVectorLength):
1815         (JSC::JSObject::ensureLengthSlow):
1816         (JSC::JSObject::reallocateAndShrinkButterfly):
1817         (JSC::JSObject::growOutOfLineStorage):
1818         (JSC::getBoundSlotBaseFunctionForGetterSetter):
1819         (JSC::JSObject::getEnumerableLength):
1820         * runtime/JSObject.h:
1821         (JSC::JSObject::getArrayLength):
1822         (JSC::JSObject::getVectorLength):
1823         (JSC::JSObject::canGetIndexQuickly):
1824         (JSC::JSObject::getIndexQuickly):
1825         (JSC::JSObject::tryGetIndexQuickly):
1826         (JSC::JSObject::canSetIndexQuickly):
1827         (JSC::JSObject::canSetIndexQuicklyForPutDirect):
1828         (JSC::JSObject::setIndexQuickly):
1829         (JSC::JSObject::initializeIndex):
1830         (JSC::JSObject::hasSparseMap):
1831         (JSC::JSObject::inSparseIndexingMode):
1832         (JSC::JSObject::inlineStorage):
1833         (JSC::JSObject::butterfly):
1834         (JSC::JSObject::outOfLineStorage):
1835         (JSC::JSObject::locationForOffset):
1836         (JSC::JSObject::ensureInt32):
1837         (JSC::JSObject::ensureDouble):
1838         (JSC::JSObject::ensureContiguous):
1839         (JSC::JSObject::ensureArrayStorage):
1840         (JSC::JSObject::arrayStorage):
1841         (JSC::JSObject::arrayStorageOrNull):
1842         (JSC::JSObject::ensureLength):
1843         (JSC::JSObject::putDirectWithoutTransition):
1844         * runtime/MapData.h:
1845         (JSC::JSIterator>::IteratorData::next):
1846         (JSC::JSIterator>::IteratorData::refreshCursor):
1847         * runtime/MapDataInlines.h:
1848         (JSC::JSIterator>::find):
1849         (JSC::JSIterator>::add):
1850         (JSC::JSIterator>::remove):
1851         (JSC::JSIterator>::replaceAndPackBackingStore):
1852         (JSC::JSIterator>::replaceBackingStore):
1853         (JSC::JSIterator>::ensureSpaceForAppend):
1854         (JSC::JSIterator>::visitChildren):
1855         (JSC::JSIterator>::copyBackingStore):
1856         * runtime/Options.h:
1857
1858 2016-03-15  Saam barati  <sbarati@apple.com>
1859
1860         Destructuring parameters are evaluated in the wrong scope
1861         https://bugs.webkit.org/show_bug.cgi?id=155454
1862
1863         Reviewed by Geoffrey Garen.
1864
1865         This patch makes our engine compatible with how parameter
1866         lists are evaluated in ES6. A parameter list that contains
1867         a rest parameter, any destructuring patterns, or default parameter values, 
1868         is classified as being non-simple. Non-simple parameter lists
1869         must get their own scope to live in, and the variables in the
1870         scope are under TDZ. This means that functions evaluated in the
1871         parameter list don't have access to variables inside the function
1872         body. Also, non-simple parameter lists get the strict-mode arguments object.
1873
1874         * bytecompiler/BytecodeGenerator.cpp:
1875         (JSC::BytecodeGenerator::BytecodeGenerator):
1876         (JSC::BytecodeGenerator::~BytecodeGenerator):
1877         (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
1878         (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
1879         * bytecompiler/BytecodeGenerator.h:
1880         * parser/Nodes.h:
1881         (JSC::FunctionParameters::size):
1882         (JSC::FunctionParameters::at):
1883         (JSC::FunctionParameters::append):
1884         (JSC::FunctionParameters::hasDefaultParameterValues): Deleted.
1885         * tests/es6.yaml:
1886         * tests/stress/parameter-scoping.js: Added.
1887         (assert):
1888         (test):
1889         (test.foo):
1890         (test.):
1891
1892 2016-03-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1893
1894         [JSC] Don't reference the properties of @Reflect directly
1895         https://bugs.webkit.org/show_bug.cgi?id=155436
1896
1897         Reviewed by Geoffrey Garen.
1898
1899         Reflect.ownKeys and Reflect.getOwnPropertyDescriptor can be altered with the user-crafted values.
1900         Instead of referencing them directly, let's reference them through private names.
1901
1902         * builtins/ObjectConstructor.js:
1903         (assign):
1904         * runtime/CommonIdentifiers.h:
1905         * runtime/ObjectConstructor.cpp:
1906         (JSC::ObjectConstructor::finishCreation): Deleted.
1907         * runtime/ReflectObject.cpp:
1908         (JSC::ReflectObject::finishCreation):
1909         * tests/stress/object-assign-correctness.js:
1910         (runTests.):
1911         (runTests.get let):
1912         (Reflect.ownKeys):
1913         (Reflect.getOwnPropertyDescriptor):
1914         (test.let.handler.switch.case.string_appeared_here.return.get enumerable): Deleted.
1915         (test.let.handler.getOwnPropertyDescriptor): Deleted.
1916         (test.let.handler.ownKeys): Deleted.
1917         (test.let.handler.get getProps): Deleted.
1918         (test.let.handler): Deleted.
1919         (test): Deleted.
1920
1921 2016-03-14  Daniel Bates  <dabates@apple.com>
1922
1923         Web Inspector: Display Content Security Policy hash in details sidebar for script and style elements
1924         https://bugs.webkit.org/show_bug.cgi?id=155466
1925         <rdar://problem/25152480>
1926
1927         Reviewed by Joseph Pecoraro and Timothy Hatcher.
1928
1929         Add property contentSecurityPolicyHash to store the CSP hash for an HTML style element or an
1930         applicable HTML script element.
1931
1932         * inspector/protocol/DOM.json:
1933
1934 2016-03-14  Joonghun Park  <jh718.park@samsung.com>
1935
1936         Purge PassRefPtr from ArrayBuffer, ArchiveResource, Pasteboard, LegacyWebArchive and DataObjectGtk
1937         https://bugs.webkit.org/show_bug.cgi?id=150497
1938
1939         Reviewed by Darin Adler.
1940
1941         * runtime/ArrayBuffer.h:
1942         (JSC::ArrayBuffer::create):
1943         (JSC::ArrayBuffer::createAdopted):
1944         (JSC::ArrayBuffer::createFromBytes):
1945         (JSC::ArrayBuffer::createUninitialized):
1946         (JSC::ArrayBuffer::slice):
1947         (JSC::ArrayBuffer::sliceImpl):
1948
1949 2016-03-14  Benjamin Poulain  <bpoulain@apple.com>
1950
1951         Andy VanWagoner no longer has time to own Intl
1952
1953         * features.json:
1954         Andy is busy with other things.
1955
1956         Andy, thanks for your amazing work on Intl and your dedication
1957         to making things right.
1958
1959 2016-03-14  Julien Brianceau  <jbriance@cisco.com>
1960
1961         [mips] Fix unaligned access in LLINT.
1962         https://bugs.webkit.org/show_bug.cgi?id=153228
1963
1964         Address loads used with btbxx opcodes were wrongly converted to lw
1965         instruction instead of lbu, leading to unaligned access on mips
1966         platforms. This is not a bug as it's silently fixed up by kernel,
1967         but it's more efficient to avoid unaligned accesses for mips.
1968
1969         Reviewed by Geoffrey Garen.
1970
1971         * offlineasm/mips.rb:
1972
1973 2016-03-14  Filip Pizlo  <fpizlo@apple.com>
1974
1975         REGRESSION(r194394): >2x slow-down on CDjs
1976         https://bugs.webkit.org/show_bug.cgi?id=155471
1977
1978         Unreviewed (rollout).
1979
1980         This revision changes localeCompare() so that it's *much* slower than before. It's
1981         understandable that sometimes things will get a tiny bit slower when implementing new
1982         language features, but more than 2x regression on a major benchmark is not OK.
1983
1984         This rolls out that change. We can reland it once we think about how to do it in a
1985         performant way.
1986
1987         * builtins/StringPrototype.js:
1988         (search):
1989         (localeCompare): Deleted.
1990         * runtime/StringPrototype.cpp:
1991         (JSC::StringPrototype::finishCreation):
1992
1993 2016-03-14  Mark Lam  <mark.lam@apple.com>
1994
1995         Need to distinguish between Symbol() and Symbol("").
1996         https://bugs.webkit.org/show_bug.cgi?id=155438
1997
1998         Reviewed by Saam Barati.
1999
2000         * runtime/PrivateName.h:
2001         (JSC::PrivateName::PrivateName):
2002
2003 2016-03-14  Oliver Hunt  <oliver@apple.com>
2004
2005         Temporarily disable the separated heap.
2006         https://bugs.webkit.org/show_bug.cgi?id=155472
2007
2008         Reviewed by Geoffrey Garen.
2009
2010         Temporarily disable this.
2011
2012         * Configurations/FeatureDefines.xcconfig:
2013
2014 2016-03-14  Joseph Pecoraro  <pecoraro@apple.com>
2015
2016         Reduce generated JSON HeapSnapshot size
2017         https://bugs.webkit.org/show_bug.cgi?id=155460
2018
2019         Reviewed by Geoffrey Garen.
2020
2021         Adjust the HeapSnapshot JSON to better reduce its size.
2022         Changes include:
2023
2024           - avoid inner array groups and instead just have a large array for
2025             nodes/edges. This removes lots of small array allocations.
2026           - eliminate duplicate edges
2027           - avoid duplicating edge names by including them in their own table;
2028           - now both the nodes and edges lists hold only integers
2029
2030         * heap/HeapSnapshotBuilder.cpp:
2031         (JSC::HeapSnapshotBuilder::json):
2032         Add some more documentation for the slightly modified format.
2033         While generating, clear data structures as early as possible.
2034
2035         * heap/HeapSnapshotBuilder.h:
2036         (JSC::HeapSnapshotEdge::HeapSnapshotEdge):
2037         During JSON building, the edge's cell pointers are converted to the
2038         identifier they point to. This avoids having to re-lookup the identifier.
2039
2040         * tests/heapProfiler/driver/driver.js:
2041         (CheapHeapSnapshotEdge):
2042         (CheapHeapSnapshot):
2043         (CheapHeapSnapshot.prototype.edgeNameFromTableIndex):
2044         (HeapSnapshot):
2045         Update test driver for slightly different snapshot format.
2046
2047 2016-03-14  Keith Miller  <keith_miller@apple.com>
2048
2049         We should be able to eliminate cloned arguments objects that use the length property
2050         https://bugs.webkit.org/show_bug.cgi?id=155391
2051
2052         Reviewed by Geoffrey Garen.
2053
2054         Previously if a programmer tried to use arguments.length in a strict function we would not eliminate the
2055         arguments object. We were unable to eliminate the arguments object because the user would get a cloned arguments
2056         object, which does not special case the length property. Thus, in order to get arguments elimination for cloned
2057         we need to add a special case. There are two things that need to happen for the elimination to succeed.
2058
2059         First, we need to eliminate the CheckStructure blocking the GetByOffset for the length property. In order to
2060         eliminate the check structure we need to prove to the Abstract Interpreter that this structure check is
2061         unnesssary. This didn't occur before for two reasons: 1) CreateClonedArguments did not set the structure it
2062         produced. 2) Even if CreateClonedArguments provided the global object's cloned arguments structure we would
2063         transition the new argements object when we added the length property during construction. To fix the second
2064         problem we now pre-assign a slot on clonedArgumentsStructure for the length property. Additionally, in order to
2065         prevent future transitions of the structure we need to choose an indexing type for the structure. Since, not
2066         eliminating the arguments object is so expensive we choose to have all cloned arguments start with continuous
2067         indexing type, this avoids transitioning when otherwise we would not have to. In the future we should be smarter
2068         about choosing the indexing type but since its relatively rare to have a arguments object escape we don't worry
2069         about this for now.
2070
2071         Additionally, this patch renames all former references of outOfBandArguments to clonedArguments and adds
2072         extra instrumentation to DFGArgumentsEliminationPhase.
2073
2074         * bytecode/BytecodeList.json:
2075         * bytecode/BytecodeUseDef.h:
2076         (JSC::computeUsesForBytecodeOffset):
2077         (JSC::computeDefsForBytecodeOffset):
2078         * bytecode/CodeBlock.cpp:
2079         (JSC::CodeBlock::dumpBytecode):
2080         * bytecode/ValueRecovery.h:
2081         (JSC::ValueRecovery::clonedArgumentsThatWereNotCreated):
2082         (JSC::ValueRecovery::outOfBandArgumentsThatWereNotCreated): Deleted.
2083         * bytecompiler/BytecodeGenerator.cpp:
2084         (JSC::BytecodeGenerator::BytecodeGenerator):
2085         * dfg/DFGAbstractInterpreterInlines.h:
2086         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2087         * dfg/DFGArgumentsEliminationPhase.cpp:
2088         * dfg/DFGByteCodeParser.cpp:
2089         (JSC::DFG::ByteCodeParser::parseBlock):
2090         * dfg/DFGCapabilities.cpp:
2091         (JSC::DFG::capabilityLevel):
2092         * dfg/DFGOperations.cpp:
2093         * dfg/DFGSpeculativeJIT.cpp:
2094         (JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
2095         * dfg/DFGStructureRegistrationPhase.cpp:
2096         (JSC::DFG::StructureRegistrationPhase::run):
2097         * dfg/DFGVariableEventStream.cpp:
2098         (JSC::DFG::VariableEventStream::tryToSetConstantRecovery):
2099         * ftl/FTLLowerDFGToB3.cpp:
2100         (JSC::FTL::DFG::LowerDFGToB3::compileCreateClonedArguments):
2101         * ftl/FTLOperations.cpp:
2102         (JSC::FTL::operationMaterializeObjectInOSR):
2103         * jit/JIT.cpp:
2104         (JSC::JIT::privateCompileMainPass):
2105         * jit/JIT.h:
2106         * jit/JITOpcodes.cpp:
2107         (JSC::JIT::emit_op_create_cloned_arguments):
2108         (JSC::JIT::emit_op_create_out_of_band_arguments): Deleted.
2109         * llint/LowLevelInterpreter.asm:
2110         * runtime/ClonedArguments.cpp:
2111         (JSC::ClonedArguments::ClonedArguments):
2112         (JSC::ClonedArguments::createEmpty):
2113         (JSC::ClonedArguments::createWithInlineFrame):
2114         (JSC::ClonedArguments::createByCopyingFrom):
2115         (JSC::ClonedArguments::createStructure):
2116         * runtime/ClonedArguments.h:
2117         * runtime/JSGlobalObject.cpp:
2118         (JSC::JSGlobalObject::init):
2119         (JSC::JSGlobalObject::visitChildren):
2120         * runtime/JSGlobalObject.h:
2121         (JSC::JSGlobalObject::clonedArgumentsStructure):
2122         (JSC::JSGlobalObject::outOfBandArgumentsStructure): Deleted.
2123
2124 2016-03-14  Saam barati  <sbarati@apple.com>
2125
2126         [ES6] Make JSON.stringify ES6 compatible
2127         https://bugs.webkit.org/show_bug.cgi?id=155448
2128
2129         Reviewed by Sam Weinig and Mark Lam.
2130
2131         We weren't following the spec with respect to the "toJSON" property
2132         of the thing being stringified. We were perform hasProperty(.)
2133         on "toJSON" instead of get(.). This patch changes it our
2134         implementation to perform get(value, "toJSON").
2135
2136         * runtime/JSCJSValue.h:
2137         * runtime/JSCJSValueInlines.h:
2138         (JSC::JSValue::isFunction):
2139         (JSC::JSValue::isCallable):
2140         * runtime/JSONObject.cpp:
2141         (JSC::Stringifier::toJSON):
2142         (JSC::Stringifier::toJSONImpl):
2143         (JSC::Stringifier::appendStringifiedValue):
2144         * tests/es6.yaml:
2145         * tests/stress/proxy-json.js:
2146         (test):
2147         (test.let.handler.get assert):
2148         (test.let.handler):
2149
2150 2016-03-14  Saam barati  <sbarati@apple.com>
2151
2152         [ES6] Disallow var assignments in for-in loops
2153         https://bugs.webkit.org/show_bug.cgi?id=155451
2154
2155         Reviewed by Mark Lam.
2156
2157         We're doing this in its own patch instead of the patch for https://bugs.webkit.org/show_bug.cgi?id=155384
2158         because last time we made this change it broke some websites. Lets try making
2159         it again because it's what the ES6 mandates. If it still breaks things we will
2160         roll it out.
2161
2162         * parser/Parser.cpp:
2163         (JSC::Parser<LexerType>::parseForStatement):
2164
2165 2016-03-14  Saam barati  <sbarati@apple.com>
2166
2167         assignments in for-in/for-of header not allowed
2168         https://bugs.webkit.org/show_bug.cgi?id=155384
2169
2170         Reviewed by Darin Adler.
2171
2172         This patch prevents assignments to the loop variable
2173         in for in/of loops in all but one situation. The following
2174         syntax is still allowed even though the spec prevents it:
2175         ```
2176         for (var i = X in blah) ;
2177         ```
2178         If the loop contains let/const, destructuring, or is a for-of
2179         loop, we always throw a syntax error if there is an assignment.
2180         We can do this with full backwards compatibility.
2181         We only allow the above type of for-in loops because Oliver told
2182         me that when he tried to make such programs illegal he ran
2183         into real websites breaking.
2184
2185         This patch also removed the !::CreatesAST compile-time branch when checking
2186         assignments to new.target. This was a dangerous thing for me
2187         to introduce into our parser. There are times where ::CreatesAST
2188         is true but we also want to check for syntax errors. For example,
2189         when parsing the top-level AST of a program. Though this check
2190         was technically correct, it's dangerous to have. It was correct
2191         because we would always be reparsing the new.target assignment
2192         because new.target is only allowed inside a function. That made it
2193         so that (!::CreatesAST <=> we care about new.target assignment syntax errors).
2194         But, (!::CreatesAST <=> we care about syntax error X) is not true in general.
2195         I think it's safer to remove such code.
2196
2197         * parser/ASTBuilder.h:
2198         (JSC::ASTBuilder::createNewTargetExpr):
2199         (JSC::ASTBuilder::isNewTarget):
2200         (JSC::ASTBuilder::createResolve):
2201         * parser/Nodes.h:
2202         (JSC::ExpressionNode::isBoolean):
2203         (JSC::ExpressionNode::isSpreadExpression):
2204         (JSC::ExpressionNode::isSuperNode):
2205         (JSC::ExpressionNode::isNewTarget):
2206         (JSC::ExpressionNode::isBytecodeIntrinsicNode):
2207         * parser/Parser.cpp:
2208         (JSC::Parser<LexerType>::parseForStatement):
2209         (JSC::Parser<LexerType>::parseAssignmentExpression):
2210         (JSC::Parser<LexerType>::parseUnaryExpression):
2211
2212 2016-03-13  Joseph Pecoraro  <pecoraro@apple.com>
2213
2214         Remove ENABLE(ES6_TEMPLATE_LITERAL_SYNTAX) guards
2215         https://bugs.webkit.org/show_bug.cgi?id=155417
2216
2217         Reviewed by Yusuke Suzuki.
2218
2219         * Configurations/FeatureDefines.xcconfig:
2220         * parser/Parser.cpp:
2221         (JSC::Parser<LexerType>::parsePrimaryExpression): Deleted.
2222         (JSC::Parser<LexerType>::parseMemberExpression): Deleted.
2223
2224 2016-03-13  Konstantin Tokarev  <annulen@yandex.ru>
2225
2226         Added new port JSCOnly.
2227         https://bugs.webkit.org/show_bug.cgi?id=154512
2228
2229         Reviewed by Michael Catanzaro.
2230
2231         This port allows to build JavaScriptCore engine with minimal
2232         dependencies.
2233
2234         * PlatformJSCOnly.cmake: Added.
2235
2236 2016-03-12  Mark Lam  <mark.lam@apple.com>
2237
2238         http://kangax.github.io/compat-table/esnext/ crashes reliably.
2239         https://bugs.webkit.org/show_bug.cgi?id=155404
2240
2241         Reviewed by Yusuke Suzuki.
2242
2243         constructObjectFromPropertyDescriptor() was incorrectly assuming that either
2244         both getter and setter will be set or unset.  It did not consider that only one
2245         of the getter or setter may be set.  This patch fixes that.
2246
2247         * runtime/ObjectConstructor.h:
2248         (JSC::constructObjectFromPropertyDescriptor):
2249         * tests/stress/proxy-with-unbalanced-getter-setter.js: Added.
2250         (assert):
2251         (let.handler.defineProperty):
2252         (i.):
2253         (i.assert):
2254         (i.get assert):
2255         (set assert):
2256
2257 2016-03-12  Brian Burg  <bburg@apple.com>
2258
2259         When generating Objective-C protocol types, getters for objects need to synthesize a new object instance
2260         https://bugs.webkit.org/show_bug.cgi?id=155389
2261         <rdar://problem/25125821>
2262
2263         Reviewed by Timothy Hatcher.
2264
2265         Currently, in object property getters for Objective-C protocol types, we use
2266         a C-style cast of the member's RWIProtocolJSONObject * to the type of the property.
2267         However, at runtime the class of `self` is going to be RWIProtocolJSONObject *,
2268         not MemberType *, so any subsequent calls to MemberType properties on the return value
2269         will fail as the selectors will not be recognized.
2270
2271         Instead of doing a C-style pointer cast, we need to create a new MemberType object
2272         that's backed by the InspectorObject retrieved from the parent object by key.
2273         This requires a new initWithJSONObject initializer for each object protocol type.
2274
2275         * inspector/scripts/codegen/generate_objc_header.py:
2276         (ObjCHeaderGenerator._generate_type_interface): Add new declaration.
2277
2278         * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
2279         (ObjCProtocolTypesImplementationGenerator.generate_type_implementation):
2280         (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_json_object): Added.
2281         Forward through to the super class initializer who assigns the underlying InspectorObject.
2282
2283         (ObjCProtocolTypesImplementationGenerator._generate_init_method_for_required_members):
2284         Drive-by cleanup to use the more compact [super init] form.
2285
2286         * inspector/scripts/codegen/objc_generator.py:
2287         (ObjCGenerator.protocol_to_objc_expression_for_member):
2288         For property getters of objects, use initWithJSONObject: rather than a C-style cast.
2289
2290         Rebaseline relevant test results.
2291
2292         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
2293         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
2294         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
2295         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
2296         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
2297         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
2298         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2299
2300 2016-03-12  Konstantin Tokarev  <annulen@yandex.ru>
2301
2302         Removed variable names from default constructor declarations.
2303         https://bugs.webkit.org/show_bug.cgi?id=155397
2304
2305         Reviewed by Mark Lam.
2306
2307         They carry no information and generate unused variable warning with GCC
2308         4.8 in a lot of source files.
2309
2310         * parser/VariableEnvironment.h:
2311
2312 2016-03-12  Myles C. Maxfield  <mmaxfield@apple.com>
2313
2314         Delete dead SVG Font code
2315         https://bugs.webkit.org/show_bug.cgi?id=154718
2316
2317         Reviewed by Antti Koivisto.
2318
2319         * Configurations/FeatureDefines.xcconfig:
2320
2321 2016-03-11  Benjamin Poulain  <bpoulain@apple.com>
2322
2323         [JSC] Remove a few jumps from DFG
2324         https://bugs.webkit.org/show_bug.cgi?id=155347
2325
2326         Reviewed by Mark Lam.
2327
2328         Usually, setting ValueTrue or ValueFalse is set
2329         by Compare+Or. There are 3 places in DFG with branches instead.
2330
2331         This patch changes them to the usual pattern.
2332
2333         * dfg/DFGSpeculativeJIT64.cpp:
2334         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
2335         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
2336
2337 2016-03-11  Saam barati  <sbarati@apple.com>
2338
2339         [ES6] Make Object.assign spec compliant
2340         https://bugs.webkit.org/show_bug.cgi?id=155375
2341
2342         Reviewed by Michael Saboff.
2343
2344         This is a straight forward implementation of Object.assign
2345         in the spec.
2346         https://tc39.github.io/ecma262/#sec-object.assign
2347         Before, weren't performing all of the specified operations.
2348         Now, we are.
2349
2350         * builtins/ObjectConstructor.js:
2351         (assign):
2352         * runtime/CommonIdentifiers.h:
2353         * runtime/JSGlobalObject.cpp:
2354         (JSC::JSGlobalObject::init):
2355         * tests/es6.yaml:
2356
2357 2016-03-11  Mark Lam  <mark.lam@apple.com>
2358
2359         Implement Function.name and Function#toString for ES6 class.
2360         https://bugs.webkit.org/show_bug.cgi?id=155336
2361
2362         Reviewed by Geoffrey Garen.
2363
2364         The only thing that the ES6 spec says about toString with regards to class
2365         objects is:
2366
2367         "The string representation must have the syntax of a FunctionDeclaration,
2368         FunctionExpression, GeneratorDeclaration, GeneratorExpression, ClassDeclaration,
2369         ClassExpression, ArrowFunction, MethodDefinition, or GeneratorMethod depending
2370         upon the actual characteristics of the object."
2371
2372         Previously, invoking toString() on a class object will return the function
2373         source string of the class' constructor function.  This does not conform to the
2374         spec in that the toString string for a class does not have the syntax of a
2375         ClassDeclaration or ClassExpression.
2376
2377         This is now fixed by doing the following:
2378
2379         1. Added "m_classSource" to FunctionExecutable (and correspondingly to
2380            UnlinkedFunctionExecutable, FunctionMetadataNode, and ClassExprNode).
2381            m_classSource is the SourceCode for the code range "class ... { ... }".
2382
2383            Since the class constructor function is the in memory representation of the
2384            class object, only class constructor functions will have its m_classSource
2385            set.  m_classSource will be "null" (by default) for all other functions.
2386            This is how we know if a FunctionExecutable is for a class.
2387
2388            Note: FunctionExecutable does not have its own m_classSource.  It always gets
2389            it from its UnlinkedFunctionExecutable.  This is ok to do because our CodeCache
2390            currently does not cache UnlinkedFunctionExecutables for class constructors.
2391
2392         2. The ClassExprNode now tracks the SourceCode range for the class expression.
2393            This is used to set m_classSource in the UnlinkedFunctionExecutable at
2394            bytecode generation time, and the FunctionExecutable later at bytecode
2395            linking time.
2396
2397         3. Function.prototype.toString() now checks if the function is for a class.
2398            If so, it returns the string for the class source instead of just the
2399            function source for the class constructor.
2400
2401            Note: the class source is static from the time the class was parsed.  This
2402            can introduces some weirdness at runtime.  Consider the following:
2403
2404                var v1 = class {}
2405                v1.toString(); // yields "class {}".
2406
2407                class c2 extends v1 {}
2408
2409                c2.__proto__ === v1; // yields true i.e. c2 extends v1.
2410                c2.toString(); // yields "class c2 extends v1 {}" which is fine.
2411
2412                v1 = {}; // point v1 to something else now.
2413
2414                c2.__proto__ === v1; // now yields false i.e. c2 no longer extends v1.
2415                                     // c2 actually extends the class that v1 used to
2416                                     // point to, but ...
2417                c2.toString(); // still yields "class c2 extends v1 {}" which is no longer true.
2418
2419            It is unclear how we can best implement toString() to avoid this issue.
2420            The above behavior is how Chrome (Version 51.0.2671.0 canary (64-bit))
2421            currently implements toString() of a class, and we do the same in this patch.
2422            In Firefox (45.0), toString() of a class will yield the function source of it
2423            constructor function, which is not better.
2424
2425         In this patch, we also added ES6 compliance for Function.name on class objects:
2426
2427         4. The ClassExprNode now has a m_ecmaName string for tracking the inferred
2428            name of a class according to the ES6 spec.  The ASTBuilder now mirrors its
2429            handling of FuncExprNodes to ClassExprNodes in setting the nodes' m_ecmaName
2430            where relevant.
2431
2432            The m_ecmaName is later used to set the m_ecmaName of the FunctionExecutable
2433            of the class constructor, which in turn is used to populate the initial value
2434            of the Function.name property.
2435
2436         5. Also renamed some variable names (/m_metadata/metadata/) to be consistent with
2437            webkit naming convention.
2438
2439         * bytecode/UnlinkedFunctionExecutable.cpp:
2440         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
2441         * bytecode/UnlinkedFunctionExecutable.h:
2442         * bytecompiler/BytecodeGenerator.cpp:
2443         (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
2444         (JSC::BytecodeGenerator::emitNewDefaultConstructor):
2445         * bytecompiler/BytecodeGenerator.h:
2446         * bytecompiler/NodesCodegen.cpp:
2447         (JSC::ClassExprNode::emitBytecode):
2448         * parser/ASTBuilder.h:
2449         (JSC::ASTBuilder::createAssignResolve):
2450         (JSC::ASTBuilder::createYield):
2451         (JSC::ASTBuilder::createClassExpr):
2452         (JSC::ASTBuilder::createFunctionExpr):
2453         (JSC::ASTBuilder::createProperty):
2454         (JSC::ASTBuilder::makeAssignNode):
2455         * parser/NodeConstructors.h:
2456         (JSC::FunctionParameters::FunctionParameters):
2457         (JSC::BaseFuncExprNode::BaseFuncExprNode):
2458         (JSC::FuncExprNode::FuncExprNode):
2459         (JSC::FuncDeclNode::FuncDeclNode):
2460         (JSC::ArrowFuncExprNode::ArrowFuncExprNode):
2461         (JSC::ClassDeclNode::ClassDeclNode):
2462         (JSC::ClassExprNode::ClassExprNode):
2463         * parser/Nodes.h:
2464         (JSC::ExpressionNode::isDestructuringNode):
2465         (JSC::ExpressionNode::isFuncExprNode):
2466         (JSC::ExpressionNode::isArrowFuncExprNode):
2467         (JSC::ExpressionNode::isClassExprNode):
2468         (JSC::ExpressionNode::isCommaNode):
2469         (JSC::ExpressionNode::isSimpleArray):
2470         (JSC::ExpressionNode::isAdd):
2471         * parser/Parser.cpp:
2472         (JSC::stringForFunctionMode):
2473         (JSC::Parser<LexerType>::parseFunctionInfo):
2474         (JSC::Parser<LexerType>::parseClass):
2475         * parser/ParserFunctionInfo.h:
2476         * parser/SyntaxChecker.h:
2477         (JSC::SyntaxChecker::createEmptyLetExpression):
2478         (JSC::SyntaxChecker::createYield):
2479         (JSC::SyntaxChecker::createClassExpr):
2480         (JSC::SyntaxChecker::createFunctionExpr):
2481         (JSC::SyntaxChecker::createFunctionMetadata):
2482         (JSC::SyntaxChecker::createArrowFunctionExpr):
2483         * runtime/Executable.cpp:
2484         (JSC::FunctionExecutable::FunctionExecutable):
2485         (JSC::FunctionExecutable::finishCreation):
2486         * runtime/Executable.h:
2487         * runtime/FunctionPrototype.cpp:
2488         (JSC::functionProtoFuncToString):
2489         * tests/es6.yaml:
2490
2491 2016-03-11  Commit Queue  <commit-queue@webkit.org>
2492
2493         Unreviewed, rolling out r197994.
2494         https://bugs.webkit.org/show_bug.cgi?id=155368
2495
2496         Broke several ARM tests (Requested by msaboff on #webkit).
2497
2498         Reverted changeset:
2499
2500         "[JSC] Add register reuse for ArithAdd of an Int32 and
2501         constant in DFG"
2502         https://bugs.webkit.org/show_bug.cgi?id=155164
2503         http://trac.webkit.org/changeset/197994
2504
2505 2016-03-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2506
2507         [ES6] Implement Reflect.set without receiver support
2508         https://bugs.webkit.org/show_bug.cgi?id=155024
2509
2510         Reviewed by Geoffrey Garen.
2511
2512         This patch implements Reflect.set.
2513         The challenge in this patch is Reflect.set requires boolean result of [[Set]],
2514         this is not propagated in the previous JSC put implementation.
2515
2516         This patch changes the put and putByIndex signature from `void put(...)` and `void putByIndex(...)` to `bool put(...)` and `bool putByIndex(...)`,
2517         more consistent style to the ECMA262 spec's [[Set]].
2518
2519         This patch modifies so many part of WebKit. But almost all the changes are mechanical ones.
2520
2521         Currently, this patch does not support receiver modification support.
2522         This will be supported in the subsequent patch[1].
2523
2524         [1]: https://bugs.webkit.org/show_bug.cgi?id=155294
2525
2526         * API/JSCallbackObject.h:
2527         * API/JSCallbackObjectFunctions.h:
2528         (JSC::JSCallbackObject<Parent>::put):
2529         (JSC::JSCallbackObject<Parent>::putByIndex):
2530         * debugger/DebuggerScope.cpp:
2531         (JSC::DebuggerScope::put):
2532         * debugger/DebuggerScope.h:
2533         * jsc.cpp:
2534         (WTF::RuntimeArray::put):
2535         * runtime/ClassInfo.h:
2536         * runtime/ClonedArguments.cpp:
2537         (JSC::ClonedArguments::put):
2538         * runtime/ClonedArguments.h:
2539         * runtime/CustomGetterSetter.cpp:
2540         (JSC::callCustomSetter):
2541         * runtime/CustomGetterSetter.h:
2542         * runtime/GenericArguments.h:
2543         * runtime/GenericArgumentsInlines.h:
2544         (JSC::GenericArguments<Type>::put):
2545         (JSC::GenericArguments<Type>::putByIndex):
2546         * runtime/GetterSetter.cpp:
2547         (JSC::callSetter):
2548         * runtime/GetterSetter.h:
2549         * runtime/JSArray.cpp:
2550         (JSC::JSArray::defineOwnProperty):
2551         (JSC::JSArray::put):
2552         (JSC::JSArray::push):
2553         * runtime/JSArray.h:
2554         * runtime/JSArrayBuffer.cpp:
2555         (JSC::JSArrayBuffer::put):
2556         * runtime/JSArrayBuffer.h:
2557         * runtime/JSArrayBufferView.cpp:
2558         (JSC::JSArrayBufferView::put):
2559         * runtime/JSArrayBufferView.h:
2560         * runtime/JSCJSValue.cpp:
2561         (JSC::JSValue::putToPrimitive):
2562         (JSC::JSValue::putToPrimitiveByIndex):
2563         * runtime/JSCJSValue.h:
2564         * runtime/JSCJSValueInlines.h:
2565         (JSC::JSValue::put):
2566         (JSC::JSValue::putInline):
2567         (JSC::JSValue::putByIndex):
2568         * runtime/JSCell.cpp:
2569         (JSC::JSCell::put):
2570         (JSC::JSCell::putByIndex):
2571         * runtime/JSCell.h:
2572         * runtime/JSDataView.cpp:
2573         (JSC::JSDataView::put):
2574         * runtime/JSDataView.h:
2575         * runtime/JSFunction.cpp:
2576         (JSC::JSFunction::put):
2577         (JSC::JSFunction::defineOwnProperty):
2578         * runtime/JSFunction.h:
2579         * runtime/JSGenericTypedArrayView.h:
2580         * runtime/JSGenericTypedArrayViewInlines.h:
2581         (JSC::JSGenericTypedArrayView<Adaptor>::put):
2582         (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
2583         * runtime/JSGlobalLexicalEnvironment.cpp:
2584         (JSC::JSGlobalLexicalEnvironment::put):
2585         * runtime/JSGlobalLexicalEnvironment.h:
2586         * runtime/JSGlobalObject.cpp:
2587         (JSC::JSGlobalObject::put):
2588         * runtime/JSGlobalObject.h:
2589         * runtime/JSLexicalEnvironment.cpp:
2590         (JSC::JSLexicalEnvironment::put):
2591         * runtime/JSLexicalEnvironment.h:
2592         * runtime/JSModuleEnvironment.cpp:
2593         (JSC::JSModuleEnvironment::put):
2594         * runtime/JSModuleEnvironment.h:
2595         * runtime/JSModuleNamespaceObject.cpp:
2596         (JSC::JSModuleNamespaceObject::put):
2597         (JSC::JSModuleNamespaceObject::putByIndex):
2598         * runtime/JSModuleNamespaceObject.h:
2599         * runtime/JSModuleRecord.cpp:
2600         (JSC::JSModuleRecord::instantiateDeclarations):
2601         * runtime/JSObject.cpp:
2602         (JSC::JSObject::put):
2603         (JSC::JSObject::putInlineSlow):
2604         (JSC::JSObject::putByIndex):
2605         (JSC::JSObject::putGetter):
2606         (JSC::JSObject::putSetter):
2607         (JSC::JSObject::putDirectAccessor):
2608         (JSC::JSObject::putDirectCustomAccessor):
2609         (JSC::JSObject::putDirectNonIndexAccessor):
2610         (JSC::JSObject::putIndexedDescriptor):
2611         (JSC::JSObject::defineOwnIndexedProperty):
2612         (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
2613         (JSC::JSObject::attemptToInterceptPutByIndexOnHole):
2614         (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
2615         (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
2616         (JSC::JSObject::putByIndexBeyondVectorLength):
2617         (JSC::JSObject::putDirectNativeIntrinsicGetter):
2618         (JSC::JSObject::putDirectNativeFunction):
2619         (JSC::JSObject::putDirectMayBeIndex):
2620         (JSC::validateAndApplyPropertyDescriptor):
2621         * runtime/JSObject.h:
2622         (JSC::JSObject::putByIndexInline):
2623         (JSC::JSObject::putDirect):
2624         * runtime/JSObjectInlines.h:
2625         (JSC::JSObject::putInline):
2626         * runtime/JSProxy.cpp:
2627         (JSC::JSProxy::put):
2628         (JSC::JSProxy::putByIndex):
2629         * runtime/JSProxy.h:
2630         * runtime/JSSymbolTableObject.h:
2631         (JSC::symbolTablePut):
2632         (JSC::symbolTablePutTouchWatchpointSet):
2633         (JSC::symbolTablePutInvalidateWatchpointSet):
2634         (JSC::symbolTablePutWithAttributesTouchWatchpointSet):
2635         * runtime/Lookup.h:
2636         (JSC::putEntry):
2637         (JSC::lookupPut):
2638         * runtime/ProxyObject.cpp:
2639         (JSC::ProxyObject::performPut):
2640         (JSC::ProxyObject::put):
2641         (JSC::ProxyObject::putByIndexCommon):
2642         (JSC::ProxyObject::putByIndex):
2643         * runtime/ProxyObject.h:
2644         * runtime/PutPropertySlot.h:
2645         * runtime/ReflectObject.cpp:
2646         (JSC::reflectObjectSet):
2647         * runtime/RegExpConstructor.cpp:
2648         (JSC::setRegExpConstructorInput):
2649         (JSC::setRegExpConstructorMultiline):
2650         * runtime/RegExpObject.cpp:
2651         (JSC::RegExpObject::defineOwnProperty):
2652         (JSC::regExpObjectSetLastIndexStrict):
2653         (JSC::regExpObjectSetLastIndexNonStrict):
2654         (JSC::RegExpObject::put):
2655         * runtime/RegExpObject.h:
2656         * runtime/SparseArrayValueMap.cpp:
2657         (JSC::SparseArrayValueMap::putEntry):
2658         (JSC::SparseArrayEntry::put):
2659         * runtime/SparseArrayValueMap.h:
2660         * runtime/StringObject.cpp:
2661         (JSC::StringObject::put):
2662         (JSC::StringObject::putByIndex):
2663         * runtime/StringObject.h:
2664         * tests/es6.yaml:
2665         * tests/modules/namespace.js:
2666         * tests/stress/reflect-set.js: Added.
2667         (shouldBe):
2668         (shouldThrow):
2669         (receiverCase.object2.set Cocoa):
2670         (receiverCase):
2671         (proxyCase):
2672         (objectCase.set get shouldBe):
2673         (objectCase.get shouldBe):
2674         (arrayCase.set get shouldBe):
2675         (arrayCase.get shouldBe):
2676         (arrayBufferCase.set get shouldBe):
2677         (arrayBufferCase.get shouldBe):
2678         (set get shouldBe):
2679         (get shouldBe):
2680         (argumentCase.test1):
2681         (argumentCase.test2):
2682         (argumentCase.test3):
2683         (argumentCase.test4.set get shouldBe):
2684         (argumentCase.test5.get shouldBe):
2685         (argumentStrictCase.test1):
2686         (argumentStrictCase.test2):
2687         (argumentStrictCase.test3):
2688         (argumentStrictCase.test4.set get shouldBe):
2689         (argumentStrictCase.test5.get shouldBe):
2690         (stringObjectCase.set get shouldBe):
2691         (stringObjectCase.get shouldBe):
2692         (customSetter.test1):
2693         (customSetter.test2):
2694         (customSetter.test3):
2695         (customSetter):
2696         (regExpLastIndex):
2697         (functionCase.func):
2698
2699 2016-03-10  Brian Burg  <bburg@apple.com>
2700
2701         Web Inspector: generated initWithPayload: protocol object initializers should recursively decode array and object members
2702         https://bugs.webkit.org/show_bug.cgi?id=155337
2703         <rdar://problem/25098357>
2704
2705         Reviewed by Timothy Hatcher.
2706
2707         In cases where an object member is itself an object or array, we were
2708         not calling initWithPayload: on the object member itself. So, this caused
2709         a runtime error when constructing the outer object because the generated
2710         code casted the NSDictionary/NSArray into the member's protocol object type.
2711
2712         * inspector/scripts/codegen/objc_generator.py:
2713         (ObjCGenerator.payload_to_objc_expression_for_member):
2714         Do a straightforward call to initWithPayload: for objects. For arrays,
2715         call a templated helper function which does the same thing. The helper
2716         is used to make this array decoding fit into a single generated expression.
2717
2718         Rebaseline relevant test results.
2719
2720         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
2721         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
2722         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2723
2724 2016-03-10  Keith Miller  <keith_miller@apple.com>
2725
2726         Unreviewed, fix Changelog. git merged poorly.
2727
2728 2016-03-10  Keith Miller  <keith_miller@apple.com>
2729
2730         Unreviewed, fix testapi.
2731
2732         * API/tests/TypedArrayCTest.cpp:
2733         (testAccess):
2734         (testConstructors):
2735         (forEachTypedArrayType):
2736         (testTypedArrayCAPI):
2737
2738 2016-03-10  Saam barati  <sbarati@apple.com>
2739
2740         [ES6] Make RegExp.prototype.toString spec compliant
2741         https://bugs.webkit.org/show_bug.cgi?id=155341
2742
2743         Reviewed by Filip Pizlo.
2744
2745         Before we were directly calling into the flagsString
2746         function. Instead, we must get the "flags" property
2747         of the thisObject. This will usually call into the flags
2748         getter, but not always. Specifically, you can you a Proxy
2749         to observe this behavior.
2750
2751         * runtime/RegExpPrototype.cpp:
2752         (JSC::regExpProtoFuncToString):
2753         (JSC::regExpProtoGetterGlobal):
2754         * tests/es6.yaml:
2755         * tests/es6/Proxy_internal_get_calls_RegExp.prototype.toString.js: Added.
2756         (test.get var):
2757         (test.):
2758         * tests/stress/regexp-prototype-tostring.js: Added.
2759         (assert):
2760         (test):
2761         (test.get var):
2762         (test.):
2763         (let.handler.get switch):
2764         (let.handler):
2765         (get test):
2766         (test.get RegExp):
2767
2768 2016-03-10  Benjamin Poulain  <bpoulain@apple.com>
2769
2770         [JSC] Add register reuse for ArithAdd of an Int32 and constant in DFG
2771         https://bugs.webkit.org/show_bug.cgi?id=155164
2772
2773         Reviewed by Geoffrey Garen.
2774
2775         Every "inc" in loop was looking like this:
2776             move rX, rY
2777             inc rY
2778             jo 0x230f4a200580
2779
2780         This patch add register Reuse to that case to remove
2781         the extra "move".
2782
2783         * dfg/DFGOSRExit.h:
2784         (JSC::DFG::SpeculationRecovery::SpeculationRecovery):
2785         (JSC::DFG::SpeculationRecovery::immediate):
2786         * dfg/DFGOSRExitCompiler32_64.cpp:
2787         (JSC::DFG::OSRExitCompiler::compileExit):
2788         * dfg/DFGOSRExitCompiler64.cpp:
2789         (JSC::DFG::OSRExitCompiler::compileExit):
2790         * dfg/DFGSpeculativeJIT.cpp:
2791         (JSC::DFG::SpeculativeJIT::compileArithAdd):
2792         * tests/stress/arith-add-with-constant-overflow.js: Added.
2793         (opaqueAdd):
2794
2795 2016-03-10  Keith Miller  <keith_miller@apple.com>
2796
2797         Unreviewed, build fix for r197983, hopefully.
2798
2799         * API/WebKitAvailability.h:
2800
2801 2016-03-10  Keith Miller  <keith_miller@apple.com>
2802
2803         Typed Arrays have no public facing API
2804         https://bugs.webkit.org/show_bug.cgi?id=120112
2805
2806         Reviewed by Geoffrey Garen.
2807
2808         This patch adds a new C-API (an Obj-C API will follow in the future) for Typed Arrays. The API has two sets of
2809         functions. One for Typed Arrays and another for Array Buffers. This API is intended to reflect the use of Typed
2810         Array objects in JS code. There is a method for each of the core TypedArray and Array Buffer methods.
2811         Originally, we were planning on using a separate non-JS object as the backing store instead of a JS Array Buffer
2812         but we decide to defer that idea since there was no good CF/NS API that met all the constraints we needed
2813         (Discussed further below). We also wanted to want until Shared Array Buffers had reached a more finished state
2814         to see what impact they might have on an API.
2815
2816         The API has the following Typed Array construction methods:
2817         1) Create with length (the backing buffer is zero initialized). -- JSObjectMakeTypedArray
2818         2) Create with an existing pointer and a destructor. -- JSObjectMakeTypedArrayFromBytesNoCopy
2819         3) Create with an Array Buffer object. -- JSObjectMakeTypedArrayFromArrayBuffer
2820         4) Create with an Array Buffer object with a given offset and length. -- JSObjectMakeTypedArrayFromArrayBufferWithOffset
2821
2822         The API has the following functions on Typed Array JSObjectRefs:
2823         5) Get access to a temporary void* of the backing store's data. -- JSObjectGetTypedArrayBytesPtr
2824         6) Get the length of a Typed Array object (returns 0 if it is not a Typed Array object). -- JSObjectGetTypedArrayLength
2825         7) Get the byte length of a Typed Array object (returns 0 if it is not a Typed Array object). -- JSObjectGetTypedArrayByteLength
2826         8) Get the byte offset of a Typed Array object (returns 0 if it is not a Typed Array object). -- JSObjectGetTypedArrayByteOffset
2827         9) Get a Typed Array object's Array Buffer  backing store. -- JSObjectGetTypedArrayBuffer
2828
2829         The API has the following Array Buffer construction method:
2830         10) Create with an existing pointer and a destructor. -- JSObjectMakeArrayBufferWithBytesNoCopy
2831
2832         The API has the following functions on Array Buffer JSObjectRefs:
2833         11) Get access to a temporary void* of the backing store's data. -- JSObjectGetArrayBufferBytesPtr
2834         12) Get the byte length of an Array Buffer object (returns 0 if it is not an Array Buffer object). -- JSObjectGetArrayBufferByteLength
2835
2836         The API adds the following new typedefs and enumerations:
2837         13) A typedef representing the function pointer type used to deallocate byte pointers provided to constructors. -- JSTypedArrayByesDeallocator
2838         14) An enumeration indicating the Typed Array API type of a JSValueRef. -- JSTypedArrayType
2839
2840         Finally, The API has the following function to get Typed Array Types:
2841         15)  Get the Typed Array type of a JS value. -- JSValueGetTypedArrayType
2842
2843         There are a couple of things to note about these functions. Calling JSObjectGetTypedArrayBytesPtr (5) or
2844         JSObjectGetArrayBufferBytesPtr (12) will pin and lock the ArrayBuffer's data for the remaining lifetime of that
2845         ArrayBuffer. This is because, currently, we do not have finalizers for our Array Buffers or Typed Arrays with a
2846         backing ArrayBuffer and adding one would likely incur a non-trivial cost to GC. Also, we do not have a direct
2847         way to make a Typed Array from a pointer with an offset as we do not expect using offsets to be a common use
2848         case of the API.
2849
2850         While it would have been nice to integrate our backing store with CFData or one of its subclasses, it is not
2851         possible to force a CFData/CFMutableData to be both writable and have a fixed size/backing store pointer.
2852         NSData is not writable and CFMutableData can have a fixed pointer if it is allocated with a non-zero capacity
2853         but there is no way for us to force an existing CFMutableData into this state.
2854
2855         * API/APIUtils.h: Copied from Source/JavaScriptCore/runtime/ArrayBuffer.cpp.
2856         (handleExceptionIfNeeded):
2857         (setException):
2858         * API/JSBase.h:
2859         * API/JSObjectRef.cpp:
2860         (handleExceptionIfNeeded): Deleted.
2861         * API/JSTypedArray.cpp: Added.
2862         (toJSTypedArrayType):
2863         (toTypedArrayType):
2864         (createTypedArray):
2865         (JSValueGetTypedArrayType):
2866         (JSObjectMakeTypedArray):
2867         (JSObjectMakeTypedArrayWithBytesNoCopy):
2868         (JSObjectMakeTypedArrayWithArrayBuffer):
2869         (JSObjectMakeTypedArrayWithArrayBufferAndOffset):
2870         (JSObjectGetTypedArrayBytesPtr):
2871         (JSObjectGetTypedArrayLength):
2872         (JSObjectGetTypedArrayByteLength):
2873         (JSObjectGetTypedArrayByteOffset):
2874         (JSObjectGetTypedArrayBuffer):
2875         (JSObjectMakeArrayBufferWithBytesNoCopy):
2876         (JSObjectGetArrayBufferBytesPtr):
2877         (JSObjectGetArrayBufferByteLength):
2878         * API/JSTypedArray.h: Added.
2879         * API/JSValueRef.cpp:
2880         (handleExceptionIfNeeded): Deleted.
2881         * API/JSValueRef.h:
2882         * API/JavaScript.h:
2883         * API/WebKitAvailability.h:
2884         * API/tests/TypedArrayCTest.cpp: Added.
2885         (id):
2886         (freePtr):
2887         (assertEqualsAsNumber):
2888         (testAccess):
2889         (testConstructors):
2890         (forEachTypedArrayType):
2891         (testTypedArrayCAPI):
2892         * API/tests/TypedArrayCTest.h: Added.
2893         * API/tests/testapi.c:
2894         (main):
2895         * CMakeLists.txt:
2896         * ForwardingHeaders/JavaScriptCore/JSTypedArray.h: Added.
2897         * JavaScriptCore.xcodeproj/project.pbxproj:
2898         * PlatformEfl.cmake:
2899         * PlatformGTK.cmake:
2900         * runtime/ArrayBuffer.cpp:
2901         (JSC::ArrayBuffer::transfer):
2902         * runtime/ArrayBuffer.h:
2903         (JSC::arrayBufferDestructorNull):
2904         (JSC::arrayBufferDestructorDefault):
2905         (JSC::ArrayBufferContents::ArrayBufferContents):
2906         (JSC::ArrayBufferContents::transfer):
2907         (JSC::ArrayBuffer::createAdopted):
2908         (JSC::ArrayBuffer::createFromBytes):
2909         (JSC::ArrayBuffer::ArrayBuffer):
2910         (JSC::ArrayBuffer::pinAndLock):
2911         (JSC::ArrayBufferContents::tryAllocate):
2912         (JSC::ArrayBufferContents::~ArrayBufferContents):
2913         * shell/PlatformWin.cmake:
2914
2915 2016-03-10  Saam barati  <sbarati@apple.com>
2916
2917         [ES6] Instanceof isn't spec compliant when the RHS is a Proxy with a target that is a function
2918         https://bugs.webkit.org/show_bug.cgi?id=155329
2919
2920         Reviewed by Mark Lam.
2921
2922         We use type info flags on the structure to dictate whether or not 
2923         the RHS of an instanceof is a valid RHS (i.e, a function). The solution
2924         to make Proxy a valid RHS when the Proxy's target is callable is to have
2925         two different structures for ProxyObject: one for a non-callable target 
2926         and one for a callable target.
2927
2928         * runtime/JSGlobalObject.cpp:
2929         (JSC::JSGlobalObject::init):
2930         (JSC::JSGlobalObject::visitChildren):
2931         * runtime/JSGlobalObject.h:
2932         (JSC::JSGlobalObject::moduleRecordStructure):
2933         (JSC::JSGlobalObject::moduleNamespaceObjectStructure):
2934         (JSC::JSGlobalObject::proxyObjectStructure):
2935         (JSC::JSGlobalObject::callableProxyObjectStructure):
2936         (JSC::JSGlobalObject::proxyRevokeStructure):
2937         (JSC::JSGlobalObject::wasmModuleStructure):
2938         * runtime/ProxyConstructor.cpp:
2939         (JSC::makeRevocableProxy):
2940         (JSC::constructProxyObject):
2941         (JSC::ProxyConstructor::getConstructData):
2942         * runtime/ProxyObject.cpp:
2943         (JSC::ProxyObject::ProxyObject):
2944         (JSC::ProxyObject::structureForTarget):
2945         (JSC::ProxyObject::finishCreation):
2946         * runtime/ProxyObject.h:
2947         (JSC::ProxyObject::create):
2948         (JSC::ProxyObject::createStructure):
2949         * tests/es6.yaml:
2950         * tests/stress/proxy-instanceof.js: Added.
2951         (assert):
2952         (test):
2953         (C):
2954         (test.let.handler.get if):
2955         (test.let.handler):
2956
2957 2016-03-10  Michael Saboff  <msaboff@apple.com>
2958
2959         [ES6] RegExp sticky flag should be ignored in String.match when global flag is given
2960         https://bugs.webkit.org/show_bug.cgi?id=155332
2961
2962         Reviewed by Saam Barati.
2963
2964         Removed logic from stringProtoFuncMatch that handles the case where both global and sticky flags are set.
2965
2966         * runtime/StringPrototype.cpp:
2967         (JSC::stringProtoFuncMatch):
2968
2969 2016-03-10  Michael Saboff  <msaboff@apple.com>
2970
2971         [ES6] Allow RegExp constructor to take pattern from an existing RegExp with new flags
2972         https://bugs.webkit.org/show_bug.cgi?id=155315
2973
2974         Reviewed by Saam Barati.
2975
2976         Changed to comply with section 21.2.3.1, step 5.  Eliminated syntax error.
2977
2978         In the process, change to get the VM at the top of the function.
2979
2980         Updated tests accordingly.
2981
2982         * runtime/RegExpConstructor.cpp:
2983         (JSC::constructRegExp):
2984         * tests/es6.yaml: Changed miscellaneous_RegExp_constructor_can_alter_flags.js to normal.
2985         * tests/mozilla/mozilla-tests.yaml: Disabled ecma_3/RegExp/15.10.4.1-5-n.js as it checks
2986         for the old behavior of throwing a syntax error.
2987
2988 2016-03-10  Saam barati  <sbarati@apple.com>
2989
2990         [ES6] Make ToPropertyDescriptor spec compliant
2991         https://bugs.webkit.org/show_bug.cgi?id=155313
2992
2993         Reviewed by Mark Lam.
2994
2995         We were performing HasProperty(.) and Get(.) in the same operation.
2996         This isn't valid according to the spec and it's user observable
2997         behavior with Proxy. This patch fixes ToPropertyDescriptor to use
2998         two distinct operations for HasProperty(.) and Get(.).
2999
3000         * runtime/ObjectConstructor.cpp:
3001         (JSC::ownEnumerablePropertyKeys):
3002         (JSC::toPropertyDescriptor):
3003         * tests/es6.yaml:
3004         * tests/stress/to-property-key-correctness.js: Added.
3005         (assert):
3006         (test):
3007         (test.let.handler.has):
3008         (arrayEq):
3009         (let.handler.has):
3010         (let.target):
3011         (set get let):
3012
3013 2016-03-10  Brian Burg  <bburg@apple.com>
3014
3015         Web Inspector: report the underlying parser error message when JSON parsing fails
3016         https://bugs.webkit.org/show_bug.cgi?id=155303
3017         <rdar://problem/25088939>
3018
3019         Reviewed by Timothy Hatcher.
3020
3021         * inspector/scripts/generate-inspector-protocol-bindings.py:
3022         (generate_from_specification.load_specification):
3023         Stringize the underlying error so we can see what it says.
3024
3025 2016-03-09  Joseph Pecoraro  <pecoraro@apple.com>
3026
3027         Web Inspector: JavaScript Heap Allocations Timeline
3028         https://bugs.webkit.org/show_bug.cgi?id=155287
3029         <rdar://problem/25078088>
3030
3031         Reviewed by Timothy Hatcher.
3032
3033         * inspector/InjectedScriptSource.js:
3034         (InjectedScript.prototype._describe):
3035         (InjectedScript.prototype._nodeDescription):
3036         Provide the nicer node preview more often.
3037
3038 2016-03-10  Saam barati  <sbarati@apple.com>
3039
3040         Assignment to new.target should be an early error
3041         https://bugs.webkit.org/show_bug.cgi?id=151148
3042
3043         Reviewed by Mark Lam.
3044
3045         This patch makes it so that any form of assignment to new.target
3046         is an early syntax error.
3047
3048         * parser/ASTBuilder.h:
3049         (JSC::ASTBuilder::createNewTargetExpr):
3050         (JSC::ASTBuilder::isNewTarget):
3051         (JSC::ASTBuilder::createResolve):
3052         * parser/Parser.cpp:
3053         (JSC::Parser<LexerType>::parseAssignmentExpression):
3054         (JSC::Parser<LexerType>::parseUnaryExpression):
3055         * parser/SyntaxChecker.h:
3056         (JSC::SyntaxChecker::createThisExpr):
3057         (JSC::SyntaxChecker::createSuperExpr):
3058         (JSC::SyntaxChecker::createNewTargetExpr):
3059         (JSC::SyntaxChecker::isNewTarget):
3060         (JSC::SyntaxChecker::createResolve):
3061         (JSC::SyntaxChecker::createObjectLiteral):
3062         * tests/es6.yaml:
3063         * tests/stress/new-target-syntax-errors.js: Added.
3064         (shouldBeSyntaxError):
3065         (shouldNotBeSyntaxError):
3066         * tests/stress/new-target.js:
3067         (Constructor):
3068         (doWeirdThings):
3069         (noAssign): Deleted.
3070         (catch): Deleted.
3071
3072 2016-03-08  Skachkov Oleksandr  <gskachkov@gmail.com>
3073
3074         How we load new.target in arrow functions is broken
3075         https://bugs.webkit.org/show_bug.cgi?id=155153
3076
3077         Reviewed by Saam Barati.
3078
3079         Fixed not correct approach of caching new.target. In current patch was added code feature
3080         flag that shows that current function is using new.target, when generating byte code an arrow 
3081         function we are loading new.target value to its register from arrow function lexical environment. 
3082
3083         * bytecompiler/BytecodeGenerator.cpp:
3084         (JSC::BytecodeGenerator::BytecodeGenerator):
3085         (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
3086         * bytecompiler/BytecodeGenerator.h:
3087         (JSC::BytecodeGenerator::newTarget):
3088         * parser/ASTBuilder.h:
3089         (JSC::ASTBuilder::createNewTargetExpr):
3090         (JSC::ASTBuilder::usesNewTarget):
3091         * parser/Nodes.h:
3092         (JSC::ScopeNode::usesNewTarget):
3093         * parser/ParserModes.h:
3094         * tests/stress/arrowfunction-lexical-bind-newtarget.js:
3095
3096 2016-03-09  Joseph Pecoraro  <pecoraro@apple.com>
3097
3098         Web Inspector: Get a RemoteObject or ObjectPreview from HeapSnapshot Object Identifier
3099         https://bugs.webkit.org/show_bug.cgi?id=155264
3100         <rdar://problem/25070716>
3101
3102         Reviewed by Timothy Hatcher.
3103
3104         * inspector/InjectedScript.h:
3105         * inspector/InjectedScript.cpp:
3106         (Inspector::InjectedScript::functionDetails):
3107         (Inspector::InjectedScript::previewValue):
3108         New InjectedScript methods for building Debugger.FunctionDetails
3109         or Runtime.ObjectPreview protocol objects from a JSValue.
3110
3111         * inspector/InjectedScriptSource.js:
3112         (InjectedScript.prototype.previewValue):
3113         (InjectedScript.prototype.functionDetails):
3114         (InjectedScript.prototype.getFunctionDetails):
3115         (InjectedScript.RemoteObject.prototype._isPreviewableObjectInternal):
3116         (InjectedScript.RemoteObject.prototype._createObjectPreviewForValue): Deleted.
3117         (InjectedScript.RemoteObject.prototype._appendEntryPreviews): Deleted.
3118         Share code around creating function details or object preview objects.
3119
3120         * inspector/agents/InspectorHeapAgent.cpp:
3121         (Inspector::InspectorHeapAgent::InspectorHeapAgent):
3122         (Inspector::InspectorHeapAgent::nodeForHeapObjectIdentifier):
3123         (Inspector::InspectorHeapAgent::getPreview):
3124         (Inspector::InspectorHeapAgent::getRemoteObject):
3125         * inspector/agents/InspectorHeapAgent.h:
3126         * inspector/protocol/Heap.json:
3127         New protocol methods that go from heap object identifier to a
3128         remote object or some kind of preview.
3129
3130         * inspector/scripts/codegen/generator.py:
3131         Allow runtime casts for ObjectPreview.
3132
3133 2016-03-09  Andy VanWagoner  <thetalecrafter@gmail.com>
3134
3135         [INTL] Intl Constructors not web compatible with Object.create usage
3136         https://bugs.webkit.org/show_bug.cgi?id=153679
3137
3138         Reviewed by Darin Adler.
3139
3140         Add workaround for initializing NumberFormat and DateTimeFormat objects
3141         using Object.create followed by constructor.call. This is necessary for
3142         backwards compatibility with libraries relying on v1 behavior of Intl
3143         constructors.
3144
3145         Collator does not get the workaround, since polyfills do not include it,
3146         and there are not any known instances of v2 incompatible libraries.
3147
3148         The workaround involves checking for an object that inherits from the
3149         *Format constructor, but was not actually initialized with that type. A
3150         substitute instance is created and attached to the object using a private
3151         name. The prototype functions then check for the private property to use
3152         in place of the original object.
3153
3154         Since this behavior is not part of the v2 spec, it should be removed as
3155         soon as the incompatible behavior is no longer in common use.
3156
3157         * runtime/CommonIdentifiers.h:
3158         * runtime/IntlDateTimeFormatConstructor.cpp:
3159         (JSC::callIntlDateTimeFormat):
3160         * runtime/IntlDateTimeFormatPrototype.cpp:
3161         (JSC::IntlDateTimeFormatPrototypeGetterFormat):
3162         (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
3163         * runtime/IntlNumberFormatConstructor.cpp:
3164         (JSC::callIntlNumberFormat):
3165         * runtime/IntlNumberFormatPrototype.cpp:
3166         (JSC::IntlNumberFormatPrototypeGetterFormat):
3167         (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
3168
3169 2016-03-09  Saam barati  <sbarati@apple.com>
3170
3171         Add proper JSON.stringify support for Proxy when the target is an array
3172         https://bugs.webkit.org/show_bug.cgi?id=155180
3173
3174         Reviewed by Darin Adler.
3175
3176         This patch makes the following type of program true:
3177         `JSON.stringify(new Proxy([25], {})) === "[25]"`
3178
3179         We need to change the JSON stringifier to use the IsArray test
3180         in section 7.2.2 of ES6 spec instead of the JSC inherits(JSArray::info())
3181         test.
3182
3183         This patch also adds tests for general JSON.stringify support
3184         of Proxy.
3185
3186         * runtime/ArrayConstructor.cpp:
3187         (JSC::arrayConstructorIsArray):
3188         (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
3189         * runtime/ArrayConstructor.h:
3190         (JSC::isArray):
3191         * runtime/JSONObject.cpp:
3192         (JSC::Stringifier::Holder::object):
3193         (JSC::Stringifier::appendStringifiedValue):
3194         (JSC::Stringifier::startNewLine):
3195         (JSC::Stringifier::Holder::Holder):
3196         * tests/es6.yaml:
3197         * tests/stress/proxy-json.js: Added.
3198         (assert):
3199         (test):
3200
3201 2016-03-09  Saam Barati  <sbarati@apple.com>
3202
3203         ES6: Implement lexical scoping for function definitions in strict mode
3204         https://bugs.webkit.org/show_bug.cgi?id=152844
3205
3206         Reviewed by Geoffrey Garen.
3207
3208         This patch implements block scoping for function definitions
3209         in strict mode. The implementation works as follows:
3210         
3211         - If we're in sloppy mode, function declarations work exactly
3212           as they did before this patch. I.e, function declarations are hoisted
3213           and declared like "var" variables.
3214         
3215         - If you're in strict mode and at the top of a function scope or program
3216           scope, function declarations still work like they used to. They are defined
3217           like "var" variables. This is necessary for backwards compatibility
3218           because ES5 strict mode allowed duplicate function declarations at the
3219           top-most scope of a program/function.
3220         
3221         - If you're in strict mode and inside a block statement or a switch statement,
3222           function declarations are now block scoped. All function declarations within
3223           a block are hoisted to the beginning of the block. They are not hoisted out of the 
3224           block like they are in sloppy mode. This allows for the following types of
3225           programs:
3226           ```
3227           function foo() {
3228               function bar() { return 20; }
3229               {
3230                   function bar() { return 30; }
3231                   bar(); // 30
3232               }
3233               bar(); // 20
3234           }
3235           ```
3236
3237         * bytecompiler/BytecodeGenerator.cpp:
3238         (JSC::BytecodeGenerator::BytecodeGenerator):
3239         (JSC::BytecodeGenerator::instantiateLexicalVariables):
3240         (JSC::BytecodeGenerator::emitPrefillStackTDZVariables):
3241         (JSC::BytecodeGenerator::pushLexicalScope):
3242         (JSC::BytecodeGenerator::pushLexicalScopeInternal):
3243         (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
3244         (JSC::BytecodeGenerator::popLexicalScope):
3245         (JSC::BytecodeGenerator::liftTDZCheckIfPossible):
3246         (JSC::BytecodeGenerator::pushTDZVariables):
3247         (JSC::BytecodeGenerator::getVariablesUnderTDZ):
3248         (JSC::BytecodeGenerator::emitNewRegExp):
3249         (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
3250         (JSC::BytecodeGenerator::emitNewFunctionExpression):
3251         (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
3252         * bytecompiler/BytecodeGenerator.h:
3253         * parser/ASTBuilder.h:
3254         (JSC::ASTBuilder::createSourceElements):
3255         (JSC::ASTBuilder::features):
3256         (JSC::ASTBuilder::numConstants):
3257         (JSC::ASTBuilder::createFuncDeclStatement):
3258         (JSC::ASTBuilder::createClassDeclStatement):
3259         (JSC::ASTBuilder::createBlockStatement):
3260         (JSC::ASTBuilder::createTryStatement):
3261         (JSC::ASTBuilder::createSwitchStatement):
3262         (JSC::ASTBuilder::Scope::Scope):
3263         (JSC::ASTBuilder::funcDeclarations): Deleted.
3264         * parser/NodeConstructors.h:
3265         (JSC::CaseBlockNode::CaseBlockNode):
3266         (JSC::SwitchNode::SwitchNode):
3267         (JSC::BlockNode::BlockNode):
3268         * parser/Nodes.cpp:
3269         (JSC::ScopeNode::ScopeNode):
3270         (JSC::ScopeNode::singleStatement):
3271         (JSC::ProgramNode::ProgramNode):
3272         (JSC::ModuleProgramNode::ModuleProgramNode):
3273         (JSC::EvalNode::EvalNode):
3274         (JSC::FunctionNode::FunctionNode):
3275         (JSC::VariableEnvironmentNode::VariableEnvironmentNode):
3276         * parser/Nodes.h:
3277         (JSC::VariableEnvironmentNode::VariableEnvironmentNode):
3278         (JSC::VariableEnvironmentNode::lexicalVariables):
3279         (JSC::VariableEnvironmentNode::functionStack):
3280         (JSC::ScopeNode::captures):
3281         (JSC::ScopeNode::varDeclarations):
3282         (JSC::ScopeNode::neededConstants):
3283         (JSC::ProgramNode::startColumn):
3284         (JSC::ProgramNode::endColumn):
3285         (JSC::EvalNode::startColumn):
3286         (JSC::EvalNode::endColumn):
3287         (JSC::ModuleProgramNode::startColumn):
3288         (JSC::ModuleProgramNode::endColumn):
3289         (JSC::ScopeNode::functionStack): Deleted.
3290         * parser/Parser.cpp:
3291         (JSC::Parser<LexerType>::parseInner):
3292         (JSC::Parser<LexerType>::didFinishParsing):
3293         (JSC::Parser<LexerType>::parseStatementListItem):
3294         (JSC::Parser<LexerType>::parseSwitchStatement):
3295         (JSC::Parser<LexerType>::parseBlockStatement):
3296         (JSC::Parser<LexerType>::parseStatement):
3297         (JSC::Parser<LexerType>::parseFunctionInfo):
3298         (JSC::getMetadata):
3299         (JSC::Parser<LexerType>::parseFunctionDeclaration):
3300         (JSC::Parser<LexerType>::parseExportDeclaration):
3301         * parser/Parser.h:
3302         (JSC::Scope::declareVariable):
3303         (JSC::Scope::declareFunction):
3304         (JSC::Scope::appendFunction):
3305         (JSC::Scope::takeFunctionDeclarations):
3306         (JSC::Scope::declareLexicalVariable):
3307         (JSC::Parser::currentVariableScope):
3308         (JSC::Parser::currentLexicalDeclarationScope):
3309         (JSC::Parser::currentFunctionScope):
3310         (JSC::Parser::pushScope):
3311         (JSC::Parser::popScopeInternal):
3312         (JSC::Parser::declareVariable):
3313         (JSC::Parser::declareFunction):
3314         (JSC::Parser::hasDeclaredVariable):
3315         (JSC::Parser::isFunctionMetadataNode):
3316         (JSC::Parser<LexerType>::parse):
3317         * parser/SyntaxChecker.h:
3318         (JSC::SyntaxChecker::createFuncDeclStatement):
3319         (JSC::SyntaxChecker::createClassDeclStatement):
3320         (JSC::SyntaxChecker::createBlockStatement):
3321         (JSC::SyntaxChecker::createExprStatement):
3322         (JSC::SyntaxChecker::createIfStatement):
3323         (JSC::SyntaxChecker::createContinueStatement):
3324         (JSC::SyntaxChecker::createTryStatement):
3325         (JSC::SyntaxChecker::createSwitchStatement):
3326         (JSC::SyntaxChecker::createWhileStatement):
3327         (JSC::SyntaxChecker::createWithStatement):
3328         (JSC::SyntaxChecker::createDoWhileStatement):
3329         * parser/VariableEnvironment.h:
3330         (JSC::VariableEnvironmentEntry::isExported):
3331         (JSC::VariableEnvironmentEntry::isImported):
3332         (JSC::VariableEnvironmentEntry::isImportedNamespace):
3333         (JSC::VariableEnvironmentEntry::isFunction):
3334         (JSC::VariableEnvironmentEntry::setIsCaptured):
3335         (JSC::VariableEnvironmentEntry::setIsConst):
3336         (JSC::VariableEnvironmentEntry::setIsExported):
3337         (JSC::VariableEnvironmentEntry::setIsImported):
3338         (JSC::VariableEnvironmentEntry::setIsImportedNamespace):
3339         (JSC::VariableEnvironmentEntry::setIsFunction):
3340         (JSC::VariableEnvironmentEntry::clearIsVar):
3341         (JSC::VariableEnvironment::VariableEnvironment):
3342         (JSC::VariableEnvironment::begin):
3343         (JSC::VariableEnvironment::end):
3344         * tests/es6.yaml:
3345         * tests/stress/block-scoped-function-declarations.js: Added.
3346         (assert):
3347         (test):
3348         (f.foo.bar):
3349         (f.foo.):
3350         (f.foo):
3351         (f):
3352         (assert.foo.):
3353         (assert.foo):
3354         (assert.foo.foo):
3355         (assert.foo.bar):
3356         (assert.foo.switch.case.1):
3357         (assert.foo.switch.case.2):
3358         (assert.foo.switch.foo):
3359         (assert.foo.switch.bar):
3360
3361 2016-03-09  Saam barati  <sbarati@apple.com>
3362
3363         Array.isArray support for Proxy
3364         https://bugs.webkit.org/show_bug.cgi?id=155179
3365
3366         Reviewed by Mark Lam.
3367
3368         This patch implements Array.isArray to be compliant
3369         with the ES6 spec. Specifically, it needs to interface
3370         properly with Proxy arguments.
3371         https://tc39.github.io/ecma262/#sec-isarray
3372
3373         * runtime/ArrayConstructor.cpp:
3374         (JSC::ArrayConstructor::getCallData):
3375         (JSC::arrayConstructorIsArray):
3376         (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
3377         * runtime/ArrayPrototype.cpp:
3378         (JSC::speciesConstructArray):
3379         * runtime/ProxyObject.cpp:
3380         (JSC::ProxyObject::revoke):
3381         (JSC::ProxyObject::isRevoked):
3382         (JSC::ProxyObject::visitChildren):
3383         * runtime/ProxyObject.h:
3384         (JSC::ProxyObject::target):
3385         (JSC::ProxyObject::handler):
3386         * tests/es6.yaml:
3387         * tests/stress/proxy-is-array.js: Added.
3388         (assert):
3389         (test):
3390
3391 2016-03-09  Benjamin Poulain  <bpoulain@apple.com>
3392
3393         [JSC] Fix the ARM64 MacroAssembler after r197816
3394         https://bugs.webkit.org/show_bug.cgi?id=155268
3395
3396         Reviewed by Mark Lam.
3397
3398         The patch tries to generate instructions that do not exist,
3399         causing quite fun stuff at runtime.
3400
3401         * assembler/MacroAssemblerARM64.h:
3402         (JSC::MacroAssemblerARM64::load8):
3403         (JSC::MacroAssemblerARM64::store16):
3404         (JSC::MacroAssemblerARM64::store8):
3405
3406 2016-03-09  Commit Queue  <commit-queue@webkit.org>
3407
3408         Unreviewed, rolling out r197873.
3409         https://bugs.webkit.org/show_bug.cgi?id=155262
3410
3411         "Crashes some JSC tests" (Requested by mlam on #webkit).
3412
3413         Reverted changeset:
3414
3415         "Add dumping of function expression names in CodeBlock
3416         bytecode dump."
3417         https://bugs.webkit.org/show_bug.cgi?id=155248
3418         http://trac.webkit.org/changeset/197873
3419
3420 2016-03-09  Oliver Hunt  <oliver@apple.com>
3421
3422         Fix old iOS
3423
3424         * jit/ExecutableAllocatorFixedVMPool.cpp:
3425         (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
3426
3427 2016-03-09  Oliver Hunt  <oliver@apple.com>
3428
3429         Wincairo buildfix
3430         https://bugs.webkit.org/show_bug.cgi?id=155245
3431
3432         Reviewed by Mark Lam.
3433
3434         Fix up exports for a few symbols
3435
3436         * jit/ExecutableAllocator.h:
3437         * jit/ExecutableAllocatorFixedVMPool.cpp:
3438
3439 2016-03-09  Mark Lam  <mark.lam@apple.com>
3440
3441         Add dumping of function expression names in CodeBlock bytecode dump.
3442         https://bugs.webkit.org/show_bug.cgi?id=155248
3443
3444         Reviewed by Filip Pizlo.
3445
3446         Because ...
3447         [  19] new_func_exp      loc5, loc3, f0:foo
3448
3449         ... is more informative than
3450         [  19] new_func_exp      loc5, loc3, f0
3451
3452         Anonymous functions will be dumped as <anon>.
3453
3454         * bytecode/CodeBlock.cpp:
3455         (JSC::CodeBlock::dumpFunctionExpr):
3456         (JSC::CodeBlock::dumpBytecode):
3457         * bytecode/CodeBlock.h:
3458
3459 2016-03-09  Michael Saboff  <msaboff@apple.com>
3460
3461         [ES6] Implement RegExp sticky flag and related functionality
3462         https://bugs.webkit.org/show_bug.cgi?id=155177
3463
3464         Reviewed by Saam Barati.
3465
3466         Implemented the ES6 RegExp sticky functionality.
3467
3468         There are two main behavior changes when the sticky flag is specified.
3469         1) Matching starts at lastIndex and lastIndex is updated after the match.
3470         2) The regular expression is only matched from the start position in the string.
3471         See ES6 section 21.2.5.2.2 for details.
3472
3473         Changed both the Yarr interpreter and jit to not loop to the next character for sticky RegExp's.
3474         Updated RegExp exec and match, and stringProtoFuncMatch to handle lastIndex changes.
3475
3476         Restructured the way flags are passed to and through YarrPatterns to use RegExpFlags instead of
3477         individual bools.
3478
3479         Updated tests for 'y' flag and new behavior.
3480
3481         * bytecode/CodeBlock.cpp:
3482         (JSC::regexpToSourceString):
3483         * inspector/ContentSearchUtilities.cpp:
3484         (Inspector::ContentSearchUtilities::findMagicComment):
3485         * runtime/CommonIdentifiers.h:
3486         * runtime/RegExp.cpp:
3487         (JSC::regExpFlags):
3488         (JSC::RegExpFunctionalTestCollector::outputOneTest):
3489         (JSC::RegExp::finishCreation):
3490         (JSC::RegExp::compile):
3491         (JSC::RegExp::compileMatchOnly):
3492         * runtime/RegExp.h:
3493         * runtime/RegExpKey.h:
3494         * runtime/RegExpObjectInlines.h:
3495         (JSC::RegExpObject::execInline):
3496         (JSC::RegExpObject::matchInline):
3497         * runtime/RegExpPrototype.cpp:
3498         (JSC::regExpProtoFuncCompile):
3499         (JSC::flagsString):
3500         (JSC::regExpProtoGetterMultiline):
3501         (JSC::regExpProtoGetterSticky):
3502         (JSC::regExpProtoGetterUnicode):
3503         * runtime/StringPrototype.cpp:
3504         (JSC::stringProtoFuncMatch):
3505         * tests/es6.yaml:
3506         * tests/stress/static-getter-in-names.js:
3507         (shouldBe):
3508         * yarr/RegularExpression.cpp:
3509         (JSC::Yarr::RegularExpression::Private::compile):
3510         * yarr/YarrInterpreter.cpp:
3511         (JSC::Yarr::Interpreter::tryConsumeBackReference):
3512         (JSC::Yarr::Interpreter::matchAssertionBOL):
3513         (JSC::Yarr::Interpreter::matchAssertionEOL):
3514         (JSC::Yarr::Interpreter::matchAssertionWordBoundary):
3515         (JSC::Yarr::Interpreter::matchDotStarEnclosure):
3516         (JSC::Yarr::Interpreter::matchDisjunction):
3517         (JSC::Yarr::Interpreter::Interpreter):
3518         (JSC::Yarr::ByteCompiler::atomPatternCharacter):
3519         * yarr/YarrInterpreter.h:
3520         (JSC::Yarr::BytecodePattern::BytecodePattern):
3521         (JSC::Yarr::BytecodePattern::estimatedSizeInBytes):
3522         (JSC::Yarr::BytecodePattern::ignoreCase):
3523         (JSC::Yarr::BytecodePattern::multiline):
3524         (JSC::Yarr::BytecodePattern::sticky):
3525         (JSC::Yarr::BytecodePattern::unicode):
3526         * yarr/YarrJIT.cpp:
3527         (JSC::Yarr::YarrGenerator::matchCharacterClass):
3528         (JSC::Yarr::YarrGenerator::jumpIfCharNotEquals):
3529         (JSC::Yarr::YarrGenerator::generateAssertionBOL):
3530         (JSC::Yarr::YarrGenerator::generateAssertionEOL):
3531         (JSC::Yarr::YarrGenerator::generatePatternCharacterOnce):
3532         (JSC::Yarr::YarrGenerator::generatePatternCharacterFixed):
3533         (JSC::Yarr::YarrGenerator::generateDotStarEnclosure):
3534         (JSC::Yarr::YarrGenerator::backtrack):
3535         * yarr/YarrPattern.cpp:
3536         (JSC::Yarr::YarrPatternConstructor::YarrPatternConstructor):
3537         (JSC::Yarr::YarrPatternConstructor::atomPatternCharacter):
3538         (JSC::Yarr::YarrPatternConstructor::setupAlternativeOffsets):
3539         (JSC::Yarr::YarrPatternConstructor::optimizeBOL):
3540         (JSC::Yarr::YarrPattern::compile):
3541         (JSC::Yarr::YarrPattern::YarrPattern):
3542         * yarr/YarrPattern.h:
3543         (JSC::Yarr::YarrPattern::reset):
3544         (JSC::Yarr::YarrPattern::nonwordcharCharacterClass):
3545         (JSC::Yarr::YarrPattern::ignoreCase):
3546         (JSC::Yarr::YarrPattern::multiline):
3547         (JSC::Yarr::YarrPattern::sticky):
3548         (JSC::Yarr::YarrPattern::unicode):
3549
3550 2016-03-09  Mark Lam  <mark.lam@apple.com>
3551
3552         FunctionExecutable::ecmaName() should not be based on inferredName().
3553         https://bugs.webkit.org/show_bug.cgi?id=155203
3554
3555         Reviewed by Michael Saboff.
3556
3557         The ES6 rules for how a function name should be inferred closely matches JSC's
3558         implementation with one exception:
3559             var o = {}
3560             o.foo = function() {}
3561
3562         JSC's inferredName for o.foo would be "foo".
3563         ES6 specifies that o.foo.name is "".
3564
3565         The fix is to add a distinct FunctionExecutable::ecmaName() which applies the ES6
3566         rules for inferring the initial value of Function.name.
3567
3568         * bytecode/UnlinkedFunctionExecutable.cpp:
3569         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
3570         * bytecode/UnlinkedFunctionExecutable.h:
3571         * parser/ASTBuilder.h:
3572         (JSC::ASTBuilder::createAssignResolve):
3573         (JSC::ASTBuilder::createGetterOrSetterProperty):
3574         (JSC::ASTBuilder::createProperty):
3575         (JSC::ASTBuilder::makeAssignNode):
3576         * parser/Nodes.h:
3577         * runtime/Executable.h:
3578         * runtime/JSFunction.cpp:
3579         (JSC::JSFunction::reifyName):
3580         * tests/es6.yaml:
3581
3582 2016-03-09  Michael Saboff  <msaboff@apple.com>
3583
3584         Harden JSC Root element functions from bad values
3585         https://bugs.webkit.org/show_bug.cgi?id=155234
3586
3587         Reviewed by Saam Barati.
3588
3589         Changed jsCast() to jsDynamicCast() in Root related function to protect against being
3590         called with non-Root arguments.
3591
3592         * jsc.cpp:
3593         (functionCreateElement):
3594         (functionGetElement):
3595         (functionSetElementRoot):
3596
3597 2016-03-09  Benjamin Poulain  <benjamin@webkit.org>
3598
3599         [JSC] Pick how to OSR Enter to FTL at runtime instead of compile time
3600         https://bugs.webkit.org/show_bug.cgi?id=155217
3601
3602         Reviewed by Filip Pizlo.
3603
3604         This patch addresses 2 types of problems with tiering up to FTL
3605         with OSR Entry in a loop:
3606         -When there are nested loops, it is generally valuable to enter
3607          an outer loop rather than an inner loop.
3608         -When tiering up at a point that cannot OSR Enter, we are at
3609          the mercy of the outer loop frequency to compile the right
3610          entry point.
3611
3612         The first case is significant in the test "gaussian-blur".
3613         That test has 4 nested loops. When we have an OSR Entry,
3614         the analysis phases have to be pesimistic where we enter:
3615         we do not really know what constraint can be proven from
3616         the DFG code that was running.
3617
3618         In "gaussian-blur", integer-range analysis removes pretty
3619         much all overflow checks in the inner loops of where we entered.
3620         The more outside we enter, the better code we generate.
3621
3622         Since we spend the most iterations in the inner loop, we naturally
3623         tend to OSR Enter into the 2 most inner loops, making the most
3624         pessimistic assumptions.
3625
3626         To avoid such problems, I changed how we decide where to OSR Enter.
3627         Previously, the last CheckTierUpAndOSREnter to cross the threshold
3628         was where we take the entry point for FTL.
3629
3630         What happens now is that the entry point is not decied when
3631         compiling the CheckTierUp variants. Instead, all the information
3632         we need is gathered during compilation and keept on the JITCode
3633         to be used at runtime.
3634
3635         When we try to tier up and decide to OSR Enter, we use the information
3636         we have to pick a good outer loop for OSR Entry.
3637
3638         Now the problem is outer loop do not CheckTierUpAndOSREnter often,
3639         wasting several miliseconds before entering the newly compiled FTL code.
3640
3641         To solve that, every CheckTierUpAndOSREnter has its own trigger that
3642         bypass the counter. When the FTL Code is compiled, the trigger is set
3643         and we enter through the right CheckTierUpAndOSREnter immediately.
3644
3645         ---
3646
3647         This new mechanism also solves a problem of ai-astar.
3648         When we try to tier up in ai-astar, we had nothing to compile until
3649         the outer loop is reached.
3650
3651         To make sure we reached the CheckTierUpAndOSREnter in a reasonable time,
3652         we had CheckTierUpWithNestedTriggerAndOSREnter with a special trigger.
3653
3654         With the new mechanism, we can do much better:
3655         -When we keep hitting CheckTierUpInLoop, we now have all the information
3656          we need to already start compiling the outer loop.
3657          Instead of waiting for the outer loop to be reached a few times, we compile
3658          it as soon as the inner loop is hammering CheckTierUpInLoop.
3659         -With the new triggers, the very next time we hit the outer loop, we OSR Enter.
3660
3661         This allow us to compile what we need sooner and enter sooner.
3662
3663         * dfg/DFGAbstractInterpreterInlines.h:
3664         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Deleted.
3665         * dfg/DFGClobberize.h:
3666         (JSC::DFG::clobberize): Deleted.
3667         * dfg/DFGDoesGC.cpp:
3668         (JSC::DFG::doesGC): Deleted.
3669         * dfg/DFGFixupPhase.cpp:
3670         (JSC::DFG::FixupPhase::fixupNode): Deleted.
3671         * dfg/DFGJITCode.h:
3672         * dfg/DFGJITCompiler.cpp:
3673         (JSC::DFG::JITCompiler::JITCompiler):
3674         (JSC::DFG::JITCompiler::compileEntryExecutionFlag):
3675         * dfg/DFGNodeType.h:
3676         * dfg/DFGOperations.cpp:
3677         * dfg/DFGOperations.h:
3678         * dfg/DFGPlan.h:
3679         (JSC::DFG::Plan::canTierUpAndOSREnter):
3680         * dfg/DFGPredictionPropagationPhase.cpp:
3681         (JSC::DFG::PredictionPropagationPhase::propagate): Deleted.
3682         * dfg/DFGSafeToExecute.h:
3683         (JSC::DFG::safeToExecute): Deleted.
3684         * dfg/DFGSpeculativeJIT32_64.cpp:
3685         (JSC::DFG::SpeculativeJIT::compile): Deleted.
3686         * dfg/DFGSpeculativeJIT64.cpp:
3687         (JSC::DFG::SpeculativeJIT::compile):
3688         * dfg/DFGTierUpCheckInjectionPhase.cpp:
3689         (JSC::DFG::TierUpCheckInjectionPhase::run):
3690         (JSC::DFG::TierUpCheckInjectionPhase::buildNaturalLoopToLoopHintMap):
3691         (JSC::DFG::TierUpCheckInjectionPhase::findLoopsContainingLoopHintWithoutOSREnter): Deleted.
3692         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
3693         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
3694         (JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
3695         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
3696         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
3697         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
3698
3699 2016-03-08  Filip Pizlo  <fpizlo@apple.com>
3700
3701         DFG should be able to constant-fold strings
3702         https://bugs.webkit.org/show_bug.cgi?id=155200
3703
3704         Reviewed by Geoffrey Garen.
3705
3706         This adds constant-folding of string1 + string2 and string.length. The actual folding
3707         rule is easy, but there are some gotchas.
3708
3709         The problem is that the DFG cannot allocate new JSString objects until we are on the
3710         main thread. So, DFG IR must have a node for a JSValue string constant that hasn't been
3711         created yet - i.e. it doesn't have any concrete JSValue bits yet.
3712
3713         We have the ability to speak of such things, using LazyJSValue. But that's a class, not
3714         a node type. This patch now adds a node type, LazyJSConstant, which is a Node that holds
3715         a LazyJSValue.
3716
3717         This puts us in a weird situation: AI uses JSValue to represent constants. It would take
3718         a lot of work to change it to use LazyJSValue. So, this implements the constant folding
3719         in StrengthReductionPhase. I created a bug and put a FIXME about moving these rules into
3720         AI.
3721
3722         OTOH, our experience in B3 shows that constant folding in strength reduction is quite
3723         nice. It would totally make sense to have strength reduction have constant folding rules
3724         that mirror the rules in AI, or to factor out the AI constant folding rules, the same
3725         way that B3 factors out those rules into Value methods.
3726
3727         Another issue is how to represent the cumulative result of possibly many foldings. I
3728         initially considered adding LazyJSValue kinds that represented concatenation. Folding
3729         the concatenation to a constant meand that this constant was actually a LazyJSValue that
3730         represented the concatenation of two other things. But this would get super messy if we
3731         wanted to fold an operation that uses the results of another folded operation.
3732
3733         So, the JIT thread folds string operations by creating a WTF::String that contains the
3734         result. The DFG::Graph holds a +1 on the underlying StringImpl, so we can pass the
3735         StringImpl* around without reference counting. The LazyJSValue now has a special kind
3736         that means: we created this StringImpl* on the JIT thread, and once the JIT is done, we
3737         will relinquish ownership of it. LazyJSValue has some magic to emit code for these
3738         to-be-created-JSStrings while also transferring ownership of the StringImpl from the JIT
3739         thread to the main thread and registering the JSString with the GC.
3740
3741         This just implements folding for concatenation and GetArrayLength. It's just a proof of
3742         concept for evil things I want to do later.
3743
3744         This change is a 2.5x speed-up on the string concatenation microbenchmarks I added in
3745         this patch.
3746
3747         * dfg/DFGAbstractInterpreterInlines.h:
3748         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3749         * dfg/DFGClobberize.h:
3750         (JSC::DFG::clobberize):
3751         * dfg/DFGDoesGC.cpp:
3752         (JSC::DFG::doesGC):
3753         * dfg/DFGFixupPhase.cpp:
3754         (JSC::DFG::FixupPhase::fixupNode):
3755         * dfg/DFGFrozenValue.cpp:
3756         (JSC::DFG::FrozenValue::emptySingleton):
3757         (JSC::DFG::FrozenValue::tryGetString):
3758         (JSC::DFG::FrozenValue::dumpInContext):
3759         * dfg/DFGFrozenValue.h:
3760         (JSC::DFG::FrozenValue::strength):
3761         * dfg/DFGGraph.h:
3762         * dfg/DFGLazyJSValue.cpp:
3763         (JSC::DFG::LazyJSValue::newString):
3764         (JSC::DFG::LazyJSValue::getValue):
3765         (JSC::DFG::equalToStringImpl):
3766         (JSC::DFG::LazyJSValue::tryGetStringImpl):
3767         (JSC::DFG::LazyJSValue::tryGetString):
3768         (JSC::DFG::LazyJSValue::strictEqual):
3769         (JSC::DFG::LazyJSValue::switchLookupValue):
3770         (JSC::DFG::LazyJSValue::emit):
3771         (JSC::DFG::LazyJSValue::dumpInContext):
3772         * dfg/DFGLazyJSValue.h:
3773         (JSC::DFG::LazyJSValue::LazyJSValue):
3774         (JSC::DFG::LazyJSValue::knownStringImpl):
3775         (JSC::DFG::LazyJSValue::kind):
3776         (JSC::DFG::LazyJSValue::tryGetValue):
3777         (JSC::DFG::LazyJSValue::character):
3778         (JSC::DFG::LazyJSValue::stringImpl):
3779         * dfg/DFGMayExit.cpp:
3780         (JSC::DFG::mayExit):
3781         * dfg/DFGNode.cpp:
3782         (JSC::DFG::Node::convertToIdentityOn):
3783         (JSC::DFG::Node::convertToLazyJSConstant):
3784         (JSC::DFG::Node::convertToPutHint):
3785         (JSC::DFG::Node::convertToPutClosureVarHint):
3786         (JSC::DFG::Node::tryGetString):
3787         (JSC::DFG::Node::promotedLocationDescriptor):
3788         * dfg/DFGNode.h:
3789         (JSC::DFG::Node::convertToConstant):
3790         (JSC::DFG::Node::convertToConstantStoragePointer):
3791         (JSC::DFG::Node::castConstant):
3792         (JSC::DFG::Node::hasLazyJSValue):
3793         (JSC::DFG::Node::lazyJSValue):
3794         (JSC::DFG::Node::initializationValueForActivation):
3795         * dfg/DFGNodeType.h:
3796         * dfg/DFGPredictionPropagationPhase.cpp:
3797         (JSC::DFG::PredictionPropagationPhase::propagate):
3798         * dfg/DFGSafeToExecute.h:
3799         (JSC::DFG::safeToExecute):
3800         * dfg/DFGSpeculativeJIT.cpp:
3801         (JSC::DFG::SpeculativeJIT::compileSetRegExpObjectLastIndex):
3802         (JSC::DFG::SpeculativeJIT::compileLazyJSConstant):
3803         * dfg/DFGSpeculativeJIT.h:
3804         * dfg/DFGSpeculativeJIT32_64.cpp:
3805         (JSC::DFG::SpeculativeJIT::compile):
3806         * dfg/DFGSpeculativeJIT64.cpp:
3807         (JSC::DFG::SpeculativeJIT::compile):
3808         * dfg/DFGStrengthReductionPhase.cpp:
3809         (JSC::DFG::StrengthReductionPhase::handleNode):
3810         * ftl/FTLCapabilities.cpp:
3811         (JSC::FTL::canCompile):
3812         * ftl/FTLLowerDFGToB3.cpp:
3813         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3814         (JSC::FTL::DFG::LowerDFGToB3::compileInt52Constant):
3815         (JSC::FTL::DFG::LowerDFGToB3::compileLazyJSConstant):
3816         (JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep):
3817
3818 2016-03-08  Joseph Pecoraro  <pecoraro@apple.com>
3819
3820         Web Inspector: Memory Timeline should show MemoryPressure events
3821         https://bugs.webkit.org/show_bug.cgi?id=155158
3822         <rdar://problem/25026610>
3823
3824         Reviewed by Brian Burg.
3825
3826         * inspector/protocol/Memory.json:
3827
3828 2016-03-08  Joseph Pecoraro  <pecoraro@apple.com>
3829
3830         Web Inspector: Add Heap domain start/stop tracking commands
3831         https://bugs.webkit.org/show_bug.cgi?id=155190
3832
3833         Reviewed by Brian Burg.
3834
3835         * inspector/agents/InspectorHeapAgent.cpp:
3836         (Inspector::InspectorHeapAgent::willDestroyFrontendAndBackend):
3837         (Inspector::InspectorHeapAgent::startTracking):
3838         (Inspector::InspectorHeapAgent::stopTracking):
3839         * inspector/agents/InspectorHeapAgent.h:
3840         * inspector/protocol/Heap.json:
3841
3842 2016-03-08  Joseph Pecoraro  <pecoraro@apple.com>
3843
3844         Web Inspector: Add a way to create a Heap Snapshot
3845         https://bugs.webkit.org/show_bug.cgi?id=155188
3846
3847         Reviewed by Brian Burg.
3848
3849         * inspector/agents/InspectorHeapAgent.h:
3850         * inspector/protocol/Heap.json:
3851         * inspector/agents/InspectorHeapAgent.cpp:
3852         (Inspector::InspectorHeapAgent::snapshot):
3853         Take a heap snapshot and return the JSON string result.
3854
3855         * inspector/protocol/Debugger.json:
3856         Remove unused optional inferredName. Our displayName would be inferred.
3857
3858 2016-03-08  Oliver Hunt  <oliver@apple.com>
3859
3860         Fix ios bot build.
3861
3862         * jit/ExecutableAllocatorFixedVMPool.cpp:
3863         (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
3864
3865 2016-03-08  Mark Lam  <mark.lam@apple.com>
3866
3867         Implement Function.name support for getters/setters and inferring name of function properties.
3868         https://bugs.webkit.org/show_bug.cgi?id=154865
3869
3870         Rubber-stamped by Joseph Pecoraro.
3871
3872         Follow up to the fix for this bug: adding a few small clean-ups for issues Joe
3873         pointed out in the bug.
3874
3875         * runtime/JSBoundSlotBaseFunction.cpp:
3876         (JSC::JSBoundSlotBaseFunction::create):
3877         * runtime/JSCJSValue.cpp:
3878         (JSC::JSValue::putToPrimitiveByIndex):
3879
3880 2016-03-08  Oliver Hunt  <oliver@apple.com>
3881
3882         Start moving to separated writable and executable mappings in the JIT
3883         https://bugs.webkit.org/show_bug.cgi?id=155178
3884
3885         Reviewed by Fil Pizlo.
3886
3887         Start moving to a separate writable and executable heap for the various
3888         JITs.
3889
3890         As part of our work to harden the JIT against various attacks, we're
3891         moving away from our current RWX heap and on to using separate RW and X
3892         mappings. This means that simply leaking the location of the executable
3893         mapping is not sufficient to compromise JSC, so we can continue to
3894         use direct executable pointers in our GC objects (which we need for
3895         performance), but keep the writable pointer in only a single location
3896         so that we are less likely to leak the address. To further obscure the
3897         address of the writable region we place it in an execute only region
3898         of memory so that it is not possible to read the location from 
3899         anywhere. That means an attacker must have at least partial control
3900         of PC (to call jitMemCopy) before they can start to attack the JIT.
3901
3902         This work is initially ARM64 only, as we use as the jitMemCopy is
3903         currently specific to that platform's calling conventions and layout.
3904         We're just landing it in the current form so that we can at least
3905         ensure it doesn't regress.
3906
3907         * Configurations/FeatureDefines.xcconfig:
3908         * assembler/ARM64Assembler.h:
3909         (JSC::ARM64Assembler::ldp):
3910         (JSC::ARM64Assembler::ldnp):
3911         (JSC::ARM64Assembler::fillNops):
3912         (JSC::ARM64Assembler::stp):
3913         (JSC::ARM64Assembler::stnp):
3914         (JSC::ARM64Assembler::replaceWithJump):
3915         (JSC::ARM64Assembler::replaceWithLoad):
3916         (JSC::ARM64Assembler::replaceWithAddressComputation):
3917         (JSC::ARM64Assembler::setPointer):
3918         (JSC::ARM64Assembler::repatchInt32):
3919         (JSC::ARM64Assembler::repatchCompact):
3920         (JSC::ARM64Assembler::linkJumpOrCall):
3921         (JSC::ARM64Assembler::linkCompareAndBranch):
3922         (JSC::ARM64Assembler::linkConditionalBranch):
3923         (JSC::ARM64Assembler::linkTestAndBranch):
3924         (JSC::ARM64Assembler::loadStoreRegisterPairOffset):
3925         (JSC::ARM64Assembler::loadStoreRegisterPairNonTemporal):