[ES6] Arrow function. Issue in access to this after eval('super()') within constructor
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2017-05-06  Oleksandr Skachkov  <gskachkov@gmail.com>
2
3         [ES6] Arrow function. Issue in access to this after eval('super()') within constructor
4         https://bugs.webkit.org/show_bug.cgi?id=171543
5
6         Reviewed by Saam Barati.
7
8         Current patch force to use 'this' within arrow function or eval 
9         from virtual scope each time, instead of using thisRegister.
10
11         * bytecompiler/BytecodeGenerator.cpp:
12         (JSC::BytecodeGenerator::ensureThis):
13
14 2017-05-05  Keith Miller  <keith_miller@apple.com>
15
16         Put does not properly consult the prototype chain
17         https://bugs.webkit.org/show_bug.cgi?id=171754
18
19         Reviewed by Saam Barati.
20
21         We should do a follow up that cleans up the rest of put. See:
22         https://bugs.webkit.org/show_bug.cgi?id=171759
23
24         * runtime/JSCJSValue.cpp:
25         (JSC::JSValue::putToPrimitive):
26         * runtime/JSObject.cpp:
27         (JSC::JSObject::putInlineSlow):
28         * runtime/JSObjectInlines.h:
29         (JSC::JSObject::canPerformFastPutInline):
30
31 2017-05-05  JF Bastien  <jfbastien@apple.com>
32
33         WebAssembly: Air::Inst::generate crashes on large binary on A64
34         https://bugs.webkit.org/show_bug.cgi?id=170215
35
36         Reviewed by Filip Pizlo.
37
38         ARM can't encode all offsets in a single instruction. We usualy
39         handle this type of detail early, or the macro assembler uses a
40         scratch register to take care of the large immediate. After
41         register allocation we assumed that we would never get large
42         offsets, and asserted this was the case. That was a fine
43         assumption with JavaScript, but WebAssembly ends up generating
44         stack frames which are too big to encode.
45
46         There are two places that needed to be fixed:
47             1. AirGenerate
48             2. AirLowerStackArgs
49
50         We now unconditionally pin the dataTempRegister on ARM64, and use
51         it when immediates don't fit.
52
53         Number 1. is easy: we're just incrementing SP, make sure we can
54         use a scratch register when that happens.
55
56         Number 2. is more complex: not all Inst can receive a stack
57         argument whose base register isn't SP or FP. Specifically,
58         Patchpoints and Stackmaps get very sad because they just want to
59         know the offset value, but when we materialize the offset as
60         follows:
61
62             Move (spill337), (spill201), %r0, @8735
63
64         Becomes (where %r16 is dataTempRegister):
65             Move $1404, %r16, @8736
66             Add64 %sp, %r16, @8736
67             Move (%r16), 2032(%sp), %r0, @8736
68
69         The code currently doesn't see through our little dance. To work
70         around this issue we introduce a new Air Arg kind:
71         ExtendedOffsetAddr. This is the same as a regular Addr, but with
72         an offset which may be too big to encode. Opcodes then declare
73         whether their arguments can handle such inputs, and if so we
74         generate them, otherwise we generate Addr as shown above.
75
76         None of this affects x86 because it can always encode large
77         immediates.
78
79         This patch also drive-by converts some uses of `override` to
80         `final`. It makes the code easier to grok, and maybe helps the
81         optimizer sometimes but really that doens't matter.
82
83         * assembler/MacroAssembler.h:
84         * assembler/MacroAssemblerARM64.h:
85         * b3/B3CheckSpecial.cpp:
86         (JSC::B3::CheckSpecial::admitsExtendedOffsetAddr):
87         * b3/B3CheckSpecial.h:
88         * b3/B3Common.cpp:
89         (JSC::B3::pinnedExtendedOffsetAddrRegister): keep the CPU-specific
90         pinning information in a cpp file
91         * b3/B3Common.h:
92         * b3/B3PatchpointSpecial.cpp:
93         (JSC::B3::PatchpointSpecial::admitsExtendedOffsetAddr):
94         * b3/B3PatchpointSpecial.h:
95         * b3/B3StackmapSpecial.cpp:
96         (JSC::B3::StackmapSpecial::isArgValidForRep):
97         (JSC::B3::StackmapSpecial::repForArg):
98         * b3/B3StackmapSpecial.h:
99         * b3/air/AirArg.cpp:
100         (JSC::B3::Air::Arg::isStackMemory):
101         (JSC::B3::Air::Arg::jsHash):
102         (JSC::B3::Air::Arg::dump):
103         (WTF::printInternal):
104         (JSC::B3::Air::Arg::stackAddrImpl): Deleted. There was only one
105         use of this (in AirLowerStackArgs) and it was now confusing to
106         split the logic up between these two. Inline the code that used to
107         be here into its one usepoint instead.
108         * b3/air/AirArg.h:
109         (JSC::B3::Air::Arg::extendedOffsetAddr):
110         (JSC::B3::Air::Arg::isExtendedOffsetAddr):
111         (JSC::B3::Air::Arg::isMemory):
112         (JSC::B3::Air::Arg::base):
113         (JSC::B3::Air::Arg::offset):
114         (JSC::B3::Air::Arg::isGP):
115         (JSC::B3::Air::Arg::isFP):
116         (JSC::B3::Air::Arg::isValidForm):
117         (JSC::B3::Air::Arg::forEachTmpFast):
118         (JSC::B3::Air::Arg::forEachTmp):
119         (JSC::B3::Air::Arg::asAddress):
120         (JSC::B3::Air::Arg::stackAddr): Deleted.
121         * b3/air/AirCCallSpecial.cpp:
122         (JSC::B3::Air::CCallSpecial::isValid):
123         (JSC::B3::Air::CCallSpecial::admitsExtendedOffsetAddr):
124         (JSC::B3::Air::CCallSpecial::generate):
125         * b3/air/AirCCallSpecial.h:
126         * b3/air/AirCode.cpp:
127         (JSC::B3::Air::Code::Code):
128         (JSC::B3::Air::Code::pinRegister): Check that the register wasn't
129         pinned before pinning it. It's likely a bug to pin the same
130         register twice.
131         * b3/air/AirCustom.h:
132         (JSC::B3::Air::PatchCustom::admitsExtendedOffsetAddr):
133         (JSC::B3::Air::CCallCustom::admitsExtendedOffsetAddr):
134         (JSC::B3::Air::ShuffleCustom::admitsExtendedOffsetAddr):
135         (JSC::B3::Air::EntrySwitchCustom::admitsExtendedOffsetAddr):
136         (JSC::B3::Air::WasmBoundsCheckCustom::admitsExtendedOffsetAddr):
137         * b3/air/AirGenerate.cpp:
138         (JSC::B3::Air::generate):
139         * b3/air/AirInst.h:
140         * b3/air/AirInstInlines.h:
141         (JSC::B3::Air::Inst::admitsExtendedOffsetAddr):
142         * b3/air/AirLowerStackArgs.cpp:
143         (JSC::B3::Air::lowerStackArgs):
144         * b3/air/AirPrintSpecial.cpp:
145         (JSC::B3::Air::PrintSpecial::admitsExtendedOffsetAddr):
146         (JSC::B3::Air::PrintSpecial::generate):
147         * b3/air/AirPrintSpecial.h:
148         * b3/air/AirSpecial.h:
149         * b3/air/opcode_generator.rb:
150
151 2017-05-05  Oliver Hunt  <oliver@apple.com>
152
153         Move trivial String prototype functions to JS builtins
154         https://bugs.webkit.org/show_bug.cgi?id=171737
155
156         Reviewed by Saam Barati.
157
158         Super simple change to migrate all of the old school
159         html-ifying string operations to builtin JS.
160
161         Core implementation is basically a 1-for-1 match to the spec.
162
163         * builtins/StringPrototype.js:
164         (globalPrivate.createHTML):
165         (anchor):
166         (big):
167         (blink):
168         (bold):
169         (fixed):
170         (fontcolor):
171         (fontsize):
172         (italics):
173         (link):
174         (small):
175         (strike):
176         (sub):
177         (sup):
178         * runtime/StringPrototype.cpp:
179         (JSC::StringPrototype::finishCreation):
180         (JSC::stringProtoFuncBig): Deleted.
181         (JSC::stringProtoFuncSmall): Deleted.
182         (JSC::stringProtoFuncBlink): Deleted.
183         (JSC::stringProtoFuncBold): Deleted.
184         (JSC::stringProtoFuncFixed): Deleted.
185         (JSC::stringProtoFuncItalics): Deleted.
186         (JSC::stringProtoFuncStrike): Deleted.
187         (JSC::stringProtoFuncSub): Deleted.
188         (JSC::stringProtoFuncSup): Deleted.
189         (JSC::stringProtoFuncFontcolor): Deleted.
190         (JSC::stringProtoFuncFontsize): Deleted.
191         (JSC::stringProtoFuncAnchor): Deleted.
192         (JSC::stringProtoFuncLink): Deleted.
193
194 2017-05-05  Don Olmstead  <don.olmstead@am.sony.com>
195
196         [JSC] Remove export from Intrinsic
197         https://bugs.webkit.org/show_bug.cgi?id=171752
198
199         Reviewed by Alexey Proskuryakov.
200
201         * runtime/Intrinsic.h:
202
203 2017-05-05  Saam Barati  <sbarati@apple.com>
204
205         putDirectIndex does not properly do defineOwnProperty
206         https://bugs.webkit.org/show_bug.cgi?id=171591
207         <rdar://problem/31735695>
208
209         Reviewed by Geoffrey Garen.
210
211         This patch fixes putDirectIndex and its JIT implementations to be
212         compatible with the ES6 spec. I think our code became out of date
213         when we implemented ArraySpeciesCreate since ArraySpeciesCreate may
214         return arbitrary objects. We perform putDirectIndex on that arbitrary
215         object. The behavior we want is as if we performed defineProperty({configurable:true, enumerable:true, writable:true}).
216         However, we weren't doing this. putDirectIndex assumed it could just splat
217         data into any descendent of JSObject's butterfly. For example, this means
218         we'd just splat into the butterfly of a typed array, even though a typed
219         array doesn't use its butterfly to store its indexed properties in the usual
220         way. Also, typed array properties are non-configurable, so this operation
221         should throw. This also means if we saw a ProxyObject, we'd just splat
222         into its butterfly, but this is obviously wrong because ProxyObject should
223         intercept the defineProperty operation.
224         
225         This patch fixes this issue by adding a whitelist of cell types that can
226         go down putDirectIndex's fast path. Anything not in that whitelist will
227         simply call into defineOwnProperty.
228
229         * bytecode/ByValInfo.h:
230         (JSC::jitArrayModePermitsPutDirect):
231         * dfg/DFGArrayMode.cpp:
232         (JSC::DFG::ArrayMode::refine):
233         * jit/JITOperations.cpp:
234         * runtime/ArrayPrototype.cpp:
235         (JSC::arrayProtoFuncSplice):
236         * runtime/ClonedArguments.cpp:
237         (JSC::ClonedArguments::createStructure):
238         * runtime/JSGenericTypedArrayViewInlines.h:
239         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
240         * runtime/JSObject.cpp:
241         (JSC::canDoFastPutDirectIndex):
242         (JSC::JSObject::defineOwnIndexedProperty):
243         (JSC::JSObject::putDirectIndexSlowOrBeyondVectorLength):
244         (JSC::JSObject::putDirectIndexBeyondVectorLength): Deleted.
245         * runtime/JSObject.h:
246         (JSC::JSObject::putDirectIndex):
247         (JSC::JSObject::canSetIndexQuicklyForPutDirect): Deleted.
248         * runtime/JSType.h:
249
250 2017-05-05  Guillaume Emont  <guijemont@igalia.com>
251
252         [JSC] include JSCInlines.h in ObjectInitializationScope.cpp
253         https://bugs.webkit.org/show_bug.cgi?id=171744
254
255         Reviewed by Mark Lam.
256
257         * runtime/ObjectInitializationScope.cpp:
258
259
260 2017-05-05  Carlos Garcia Campos  <cgarcia@igalia.com>
261
262         [GTK] Assertion failure in Inspector::RemoteInspector::setRemoteInspectorClient when disposing WebKitWebContext
263         https://bugs.webkit.org/show_bug.cgi?id=171644
264
265         Reviewed by Michael Catanzaro.
266
267         Fix ASSERT that requires given client to be a valid pointer, since it's valid to pass nullptr to unset the
268         client. The ASSERT now ensures that client is set or unset. I also renamed the function to setClient because
269         setRemoteInspectorClient is redundant for a class named RemoteInspector. And added a getter too, to check if the
270         remote inspector has a client.
271
272         * inspector/remote/RemoteInspector.cpp:
273         (Inspector::RemoteInspector::setClient):
274         * inspector/remote/RemoteInspector.h:
275
276 2017-05-04  Commit Queue  <commit-queue@webkit.org>
277
278         Unreviewed, rolling out r216206.
279         https://bugs.webkit.org/show_bug.cgi?id=171714
280
281         Multiple LayoutTests crashing in Document::page() (Requested
282         by ap on #webkit).
283
284         Reverted changeset:
285
286         "Remove support for legacy Notifications"
287         https://bugs.webkit.org/show_bug.cgi?id=171487
288         http://trac.webkit.org/changeset/216206
289
290 2017-05-04  Don Olmstead  <don.olmstead@am.sony.com>
291
292         [Win] Remove redundant macros that are set in the CMake config
293         https://bugs.webkit.org/show_bug.cgi?id=171571
294
295         Reviewed by Brent Fulgham.
296
297         * config.h:
298
299 2017-05-04  Mark Lam  <mark.lam@apple.com>
300
301         Gardening: Build fix for Windows after r216217.
302         https://bugs.webkit.org/show_bug.cgi?id=171586
303
304         Not reviewed.
305
306         * shell/PlatformWin.cmake:
307
308 2017-05-04  Filip Pizlo  <fpizlo@apple.com>
309
310         JSC::Heap should expose a richer API for requesting GCs
311         https://bugs.webkit.org/show_bug.cgi?id=171690
312
313         Reviewed by Geoffrey Garen.
314         
315         I want to stop WebCore from requesting synchronous GCs. But various parts of that work
316         may cause regressions, so I'd like to land it separately from the functionality that is
317         needed on the JSC side. This change is mostly a JSC-side refactoring that does not
318         change behavior. In the future I'll land the behavior changes (i.e. not requesting sync
319         GCs).
320         
321         This change allows you to enumerate over synchronousness, so that we can make all APIs
322         take synchronousness as an argument. It replaces the collectAllGarbage API with a
323         collectNow(Synchronousness, GCRequest) API. GCRequest is a new concept, which subsumes
324         std::optional<CollectionScope> and gives us the ability to register callbacks along
325         with a GC. So, you can ask for an async GC and get a callback when it's done.
326         
327         Also adds ability to request that fastMalloc memory be released after the incremental
328         sweeper finishes.
329         
330         * API/JSBase.cpp:
331         (JSSynchronousGarbageCollectForDebugging):
332         * CMakeLists.txt:
333         * JavaScriptCore.xcodeproj/project.pbxproj:
334         * heap/FullGCActivityCallback.cpp:
335         (JSC::FullGCActivityCallback::doCollection):
336         * heap/FullGCActivityCallback.h:
337         * heap/GCRequest.cpp: Added.
338         (JSC::GCRequest::subsumedBy):
339         (JSC::GCRequest::dump):
340         * heap/GCRequest.h: Added.
341         (JSC::GCRequest::GCRequest):
342         * heap/Heap.cpp:
343         (JSC::Heap::collect):
344         (JSC::Heap::collectNow):
345         (JSC::Heap::collectAsync):
346         (JSC::Heap::collectSync):
347         (JSC::Heap::runBeginPhase):
348         (JSC::Heap::runEndPhase):
349         (JSC::Heap::requestCollection):
350         (JSC::Heap::willStartCollection):
351         (JSC::Heap::sweeper):
352         (JSC::Heap::collectNowFullIfNotDoneRecently):
353         (JSC::Heap::shouldDoFullCollection):
354         (JSC::Heap::collectAllGarbage): Deleted.
355         (JSC::Heap::collectAllGarbageIfNotDoneRecently): Deleted.
356         * heap/Heap.h:
357         * heap/HeapSnapshotBuilder.cpp:
358         (JSC::HeapSnapshotBuilder::buildSnapshot):
359         * heap/IncrementalSweeper.cpp:
360         (JSC::IncrementalSweeper::doSweep):
361         * heap/IncrementalSweeper.h:
362         (JSC::IncrementalSweeper::freeFastMallocMemoryAfterSweeping):
363         * heap/MarkedAllocator.cpp:
364         (JSC::MarkedAllocator::doTestCollectionsIfNeeded):
365         * heap/MarkedSpace.cpp:
366         (JSC::MarkedSpace::sweep):
367         * heap/Synchronousness.cpp: Added.
368         (WTF::printInternal):
369         * heap/Synchronousness.h: Added.
370         * inspector/agents/InspectorHeapAgent.cpp:
371         (Inspector::InspectorHeapAgent::gc):
372         * jsc.cpp:
373         (functionGCAndSweep):
374         (runJSC):
375         * tools/JSDollarVMPrototype.cpp:
376         (JSC::JSDollarVMPrototype::gc):
377         * wasm/WasmMemory.cpp:
378
379 2017-05-04  Mark Lam  <mark.lam@apple.com>
380
381         NeverDestroyed<String>(ASCIILiteral(...)) is not thread safe.
382         https://bugs.webkit.org/show_bug.cgi?id=171586
383         <rdar://problem/31873190>
384
385         Reviewed by Yusuke Suzuki.
386
387         JavaScriptCore allows multiple VMs to be instantiated, and each of these should
388         be able to run concurrently on different threads.  There is code in the VM that
389         allocates NeverDestroyed<String>(ASCIILiteral(...)) to defined immortal strings
390         meant to be shared by all VMs.
391
392         However, NeverDestroyed<String>(ASCIILiteral(...)) is not thread-safe because
393         each thread will ref and deref the underlying StringImpl.  Since this ref and
394         deref is not done in a thread-safe way, the NeverDestroyed<String> may get
395         destroyed due to the ref/deref races.  Additionally, each thread may modify the
396         StringImpl by setting its hash and also twiddling its flags.
397
398         The fix is to use the StaticStringImpl class which is safe for ref/derefing
399         concurrently from different threads.  StaticStringImpl is also pre-set with a
400         hash on construction, and its flags are set in such a way as to prevent twiddling
401         at runtime.  Hence, we will be able to share a NeverDestroyed<String> between
402         VMs, as long as it is backed by a StaticStringImpl.
403
404         An alternative solution would be to change all the uses of NeverDestroyed<String>
405         to use per-VM strings.  However, this solution is cumbersome, and makes it harder
406         to allocate the intended shared string.  It also uses more memory and takes more
407         CPU time because it requires allocating the same string for each VM instance.
408         The StaticStringImpl solution wins out because it is more efficient and is easier
409         to use.
410
411         The StaticStringImpl solution also can be used in WTF without a layer violation.
412         See Source/WTF/wtf/text/icu/TextBreakIteratorICU.h for an example.
413
414         Also added the MultithreadedMultiVMExecutionTest which runs multiple VMs in
415         multiple threads, all banging on the BuiltinExecutable's baseConstructorCode
416         NeverDestroyed<String>.  The test will manifest the issue reliably (before this
417         fix) if run on an ASAN build.
418
419         * API/tests/MultithreadedMultiVMExecutionTest.cpp: Added.
420         (threadsList):
421         (startMultithreadedMultiVMExecutionTest):
422         (finalizeMultithreadedMultiVMExecutionTest):
423         * API/tests/MultithreadedMultiVMExecutionTest.h: Added.
424         * API/tests/testapi.c:
425         (main):
426         * JavaScriptCore.xcodeproj/project.pbxproj:
427         * builtins/BuiltinExecutables.cpp:
428         (JSC::BuiltinExecutables::createDefaultConstructor):
429         * inspector/agents/InspectorDebuggerAgent.cpp:
430         (Inspector::objectGroupForBreakpointAction):
431         * replay/scripts/CodeGeneratorReplayInputsTemplates.py:
432         * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.cpp:
433         (JSC::InputTraits<Test::SavedMouseButton>::type):
434         * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.cpp:
435         (JSC::InputTraits<Test::SavedMouseButton>::type):
436         * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.cpp:
437         (JSC::InputTraits<Test::HandleWheelEvent>::type):
438         * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.cpp:
439         (JSC::InputTraits<Test::FormCombo>::type):
440         * replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.cpp:
441         (JSC::InputTraits<Test::GetCurrentTime>::type):
442         (JSC::InputTraits<Test::SetRandomSeed>::type):
443         * replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.cpp:
444         (JSC::InputTraits<Test::ArrayOfThings>::type):
445         (JSC::InputTraits<Test::SavedHistory>::type):
446         * replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.cpp:
447         (JSC::InputTraits<Test::ScalarInput1>::type):
448         (JSC::InputTraits<Test::ScalarInput2>::type):
449         * replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.cpp:
450         (JSC::InputTraits<Test::ScalarInput>::type):
451         (JSC::InputTraits<Test::MapInput>::type):
452         * runtime/IntlObject.cpp:
453         (JSC::numberingSystemsForLocale):
454
455 2017-05-04  Sam Weinig  <sam@webkit.org>
456
457         Remove support for legacy Notifications
458         https://bugs.webkit.org/show_bug.cgi?id=171487
459
460         Reviewed by Jon Lee.
461
462         * Configurations/FeatureDefines.xcconfig:
463         Remove definition of ENABLE_LEGACY_NOTIFICATIONS.
464
465 2017-05-04  Konstantin Tokarev  <annulen@yandex.ru>
466
467         Fix compilation with ICU 59.1
468         https://bugs.webkit.org/show_bug.cgi?id=171612
469
470         Reviewed by Mark Lam.
471
472         ICU 59.1 has broken source compatibility. Now it defines UChar as
473         char16_t, which does not allow automatic type conversion from unsigned
474         short in C++ code.
475
476         * API/JSStringRef.cpp:
477         (JSStringCreateWithCharacters):
478         (JSStringCreateWithCharactersNoCopy):
479         (JSStringGetCharactersPtr):
480         * runtime/DateConversion.cpp:
481         (JSC::formatDateTime):
482
483 2017-05-04  Saam Barati  <sbarati@apple.com>
484
485         stress/call-apply-exponential-bytecode-size.js.no-llint failing on 32-bit debug for OOM on executable memory
486         https://bugs.webkit.org/show_bug.cgi?id=171008
487
488         Reviewed by Yusuke Suzuki.
489
490         This patch lowers the threshold for .call/.apply recursion
491         in an attempt to emit less code and not impact perf.
492         We're currently failing tests on x86-32 by running out
493         of executable memory. If perf gets impacted because of this,
494         then I'll apply a stricter change just to 32-bit platforms.
495         However, if this doesn't negatively impact perf, it's all around
496         better than all platforms emit less bytecode.
497
498         * bytecompiler/NodesCodegen.cpp:
499
500 2017-05-04  Yusuke Suzuki  <utatane.tea@gmail.com>
501
502         [JSC] Math unary functions should be handled by DFG
503         https://bugs.webkit.org/show_bug.cgi?id=171269
504
505         Reviewed by Saam Barati.
506
507         ArithSin, ArithCos, and ArithLog are just calling a C runtime function.
508         While handling them in DFG is not very effective for performance, they
509         can drop some type checks & value conversions and mark them as pure
510         operations. It is effective if they are involved in some complex
511         optimization phase. Actually, ArithLog is effective in kraken.
512
513         While a few of Math functions have DFG nodes, basically math functions
514         are pure. And large part of these functions are just calling a C runtime
515         function. This patch generalizes these nodes in DFG as ArithUnary. And
516         we annotate many unary math functions with Intrinsics and convert them
517         to ArithUnary in DFG. It also cleans up duplicate code in ArithSin,
518         ArithCos, and ArithLog. If your math function has some good DFG / FTL
519         optimization rather than calling a C runtime function, you should add
520         a specialized DFG node, like ArithSqrt.
521
522         We also create a new namespace JSC::Math. Inside it, we collect math functions.
523
524         * dfg/DFGAbstractInterpreterInlines.h:
525         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
526         * dfg/DFGArithMode.cpp:
527         (JSC::DFG::arithUnaryFunction):
528         (JSC::DFG::arithUnaryOperation):
529         (WTF::printInternal):
530         * dfg/DFGArithMode.h:
531         * dfg/DFGBackwardsPropagationPhase.cpp:
532         (JSC::DFG::BackwardsPropagationPhase::propagate):
533         * dfg/DFGByteCodeParser.cpp:
534         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
535         * dfg/DFGClobberize.h:
536         (JSC::DFG::clobberize):
537         * dfg/DFGDoesGC.cpp:
538         (JSC::DFG::doesGC):
539         * dfg/DFGFixupPhase.cpp:
540         (JSC::DFG::FixupPhase::fixupNode):
541         * dfg/DFGGraph.cpp:
542         (JSC::DFG::Graph::dump):
543         * dfg/DFGNode.h:
544         (JSC::DFG::Node::hasArithUnaryType):
545         (JSC::DFG::Node::arithUnaryType):
546         * dfg/DFGNodeType.h:
547         * dfg/DFGOperations.cpp:
548         * dfg/DFGOperations.h:
549         * dfg/DFGPredictionPropagationPhase.cpp:
550         * dfg/DFGSafeToExecute.h:
551         (JSC::DFG::safeToExecute):
552         * dfg/DFGSpeculativeJIT.cpp:
553         (JSC::DFG::SpeculativeJIT::compileArithUnary):
554         (JSC::DFG::SpeculativeJIT::compileArithCos): Deleted.
555         (JSC::DFG::SpeculativeJIT::compileArithTan): Deleted.
556         (JSC::DFG::SpeculativeJIT::compileArithSin): Deleted.
557         (JSC::DFG::SpeculativeJIT::compileArithLog): Deleted.
558         * dfg/DFGSpeculativeJIT.h:
559         * dfg/DFGSpeculativeJIT32_64.cpp:
560         (JSC::DFG::SpeculativeJIT::compile):
561         * dfg/DFGSpeculativeJIT64.cpp:
562         (JSC::DFG::SpeculativeJIT::compile):
563         * ftl/FTLCapabilities.cpp:
564         (JSC::FTL::canCompile):
565         * ftl/FTLLowerDFGToB3.cpp:
566         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
567         (JSC::FTL::DFG::LowerDFGToB3::compileArithUnary):
568         (JSC::FTL::DFG::LowerDFGToB3::compileArithSin): Deleted.
569         (JSC::FTL::DFG::LowerDFGToB3::compileArithCos): Deleted.
570         (JSC::FTL::DFG::LowerDFGToB3::compileArithTan): Deleted.
571         (JSC::FTL::DFG::LowerDFGToB3::compileArithLog): Deleted.
572         * ftl/FTLOutput.cpp:
573         (JSC::FTL::Output::doubleUnary):
574         (JSC::FTL::Output::doubleSin): Deleted.
575         (JSC::FTL::Output::doubleCos): Deleted.
576         (JSC::FTL::Output::doubleTan): Deleted.
577         (JSC::FTL::Output::doubleLog): Deleted.
578         * ftl/FTLOutput.h:
579         * runtime/Intrinsic.h:
580         * runtime/MathCommon.cpp:
581         (JSC::Math::log1p):
582         * runtime/MathCommon.h:
583         * runtime/MathObject.cpp:
584         (JSC::MathObject::finishCreation):
585         (JSC::mathProtoFuncACos):
586         (JSC::mathProtoFuncASin):
587         (JSC::mathProtoFuncATan):
588         (JSC::mathProtoFuncCos):
589         (JSC::mathProtoFuncExp):
590         (JSC::mathProtoFuncLog):
591         (JSC::mathProtoFuncSin):
592         (JSC::mathProtoFuncTan):
593         (JSC::mathProtoFuncACosh):
594         (JSC::mathProtoFuncASinh):
595         (JSC::mathProtoFuncATanh):
596         (JSC::mathProtoFuncCbrt):
597         (JSC::mathProtoFuncCosh):
598         (JSC::mathProtoFuncExpm1):
599         (JSC::mathProtoFuncLog1p):
600         (JSC::mathProtoFuncLog10):
601         (JSC::mathProtoFuncLog2):
602         (JSC::mathProtoFuncSinh):
603         (JSC::mathProtoFuncTanh):
604
605 2017-05-03  Saam Barati  <sbarati@apple.com>
606
607         How we build polymorphic cases is wrong when making a call from Wasm
608         https://bugs.webkit.org/show_bug.cgi?id=171527
609
610         Reviewed by JF Bastien.
611
612         This patches fixes a bug when we emit a polymorphic call IC from
613         Wasm. We were incorrectly assuming that if we made a call *from wasm*,
614         then the thing we are *calling to* does not have a CodeBlock. This
615         is obviously wrong. This patch fixes the incorrect assumption.
616         
617         This patch also does two more things:
618         1. Add a new option that makes us make calls to JS using a
619         slow path instead of using a call IC.
620         2. Fixes a potential GC bug where we didn't populate JSWebAssemblyCodeBlock's
621         JSWebAssemblyModule pointer.
622
623         * jit/Repatch.cpp:
624         (JSC::linkPolymorphicCall):
625         * runtime/Options.h:
626         * wasm/WasmBinding.cpp:
627         (JSC::Wasm::wasmToJs):
628         * wasm/js/JSWebAssemblyCodeBlock.cpp:
629         (JSC::JSWebAssemblyCodeBlock::create):
630         (JSC::JSWebAssemblyCodeBlock::finishCreation):
631         * wasm/js/JSWebAssemblyCodeBlock.h:
632         * wasm/js/JSWebAssemblyInstance.cpp:
633         (JSC::JSWebAssemblyInstance::finalizeCreation):
634
635 2017-05-03  Keith Miller  <keith_miller@apple.com>
636
637         Array.prototype.sort should also allow a null comparator
638         https://bugs.webkit.org/show_bug.cgi?id=171621
639         <rdar://problem/30757933>
640
641         Reviewed by Michael Saboff.
642
643         It looks like sort not accepting a null comparator
644         causes some pages to stop working. Those pages work in
645         Chrome/Firefox so we should try to match them.
646
647         * builtins/ArrayPrototype.js:
648         (sort):
649
650 2017-05-03  Mark Lam  <mark.lam@apple.com>
651
652         Use the CLoop for CPU(ARM64E).
653         https://bugs.webkit.org/show_bug.cgi?id=171620
654         <rdar://problem/31973027>
655
656         Reviewed by Geoffrey Garen.
657
658         * llint/LLIntOfflineAsmConfig.h:
659         * tools/SigillCrashAnalyzer.cpp:
660         (JSC::SigillCrashAnalyzer::dumpCodeBlock):
661
662 2017-05-03  Keith Miller  <keith_miller@apple.com>
663
664         Different behaviour with the .sort(callback) method (unlike Firefox & Chrome)
665         https://bugs.webkit.org/show_bug.cgi?id=47825
666
667         Reviewed by Saam Barati.
668
669         This patch makes our sort function match the behavior of Firefox
670         and Chrome when the result of the comparison function is a
671         boolean. When we first switched to using merge sort, it regressed
672         JQuery sorting of DOM nodes by 30%. The regression was do to the
673         fact that JQuery was using compareDocumentPosition to compare the
674         locations of objects. Since one of the benchmarks would pass a
675         reverse sorted list to the sort function we would end up walking
676         the entire DOM to do comparisons. The solution to this was to
677         merge based on comparison(right, left) rather than
678         comparison(left, right). Although, in practice this does nothing
679         since sort could just as easily receive an already sorted list and
680         we're back in the same spot.
681
682         The downside of sorting with comparison(right, left) is that to
683         maintain stability when sorting, you only want to merge from right
684         when the comparison function returns a negative value. This is
685         where the problem with booleans comes in. Since booleans toNumber
686         false to 0 and true to 1 both values are "equal". This patch fixes
687         this by special casing boolean return values.
688
689
690         * builtins/ArrayPrototype.js:
691         (sort.merge):
692
693 2017-05-03  Andy VanWagoner  <thetalecrafter@gmail.com>
694
695         [INTL] Support dashed values in unicode locale extensions
696         https://bugs.webkit.org/show_bug.cgi?id=171480
697
698         Reviewed by JF Bastien.
699
700         Implements the UnicodeExtensionSubtags operation and updates the ResolveLocale operation to use it.
701         This fixes locale extensions with values that include '-'. The following calendars work now:
702         ethiopic-amete-alem
703         islamic-umalqura
704         islamic-tbla
705         islamic-civil
706         islamic-rgsa
707
708         While updating IntlObject, the comments containing spec text were replaced with a single url at the
709         top of each function pointing to the relevant part of ECMA-402.
710
711         * runtime/IntlObject.cpp:
712         (JSC::unicodeExtensionSubTags): Added.
713         (JSC::resolveLocale): Updated to latest standard.
714
715 2017-05-02  Don Olmstead  <don.olmstead@am.sony.com>
716
717         Build fix after r216078
718         https://bugs.webkit.org/show_bug.cgi?id=171554
719
720         Reviewed by Saam Barati.
721
722         * API/tests/testapi.c:
723
724 2017-05-02  Filip Pizlo  <fpizlo@apple.com>
725
726         Unreviewed, fix pedantic C compilers.
727
728         * API/tests/testapi.c:
729         (markingConstraint):
730         (testMarkingConstraints):
731
732 2017-05-02  Filip Pizlo  <fpizlo@apple.com>
733
734         Unreviewed, fix cmake build.
735
736         * CMakeLists.txt:
737
738 2017-05-02  Filip Pizlo  <fpizlo@apple.com>
739
740         JSC C API should expose GC marking constraints and weak references
741         https://bugs.webkit.org/show_bug.cgi?id=171554
742
743         Reviewed by Geoffrey Garen.
744         
745         This exposes an API that lets you participate in the GC's fixpoint. You can ask the GC
746         what is marked and you can tell the GC to mark things. The constraint callback cannot
747         do a whole lot, but it can query marking state and it can dereference weak references.
748         
749         Additionally, this exposes a very simple weak reference API in C.
750
751         * API/JSMarkingConstraintPrivate.cpp: Added.
752         (JSC::isMarked):
753         (JSC::mark):
754         (JSContextGroupRegisterMarkingConstraint):
755         * API/JSMarkingConstraintPrivate.h: Added.
756         * API/JSWeakPrivate.cpp: Added.
757         (OpaqueJSWeak::OpaqueJSWeak):
758         (JSWeakCreate):
759         (JSWeakRetain):
760         (JSWeakRelease):
761         (JSWeakGetObject):
762         * API/JSWeakPrivate.h: Added.
763         * API/tests/testapi.c:
764         (markingConstraint):
765         (testMarkingConstraints):
766         (main):
767         * JavaScriptCore.xcodeproj/project.pbxproj:
768         * heap/SlotVisitor.h:
769         * heap/SlotVisitorInlines.h:
770         (JSC::SlotVisitor::appendHiddenUnbarriered):
771         (JSC::SlotVisitor::appendHidden):
772
773 2017-05-02  Mark Lam  <mark.lam@apple.com>
774
775         JSFixedArray::allocationSize() should not allow for allocation failure.
776         https://bugs.webkit.org/show_bug.cgi?id=171516
777
778         Reviewed by Geoffrey Garen.
779
780         Since JSFixedArray::createFromArray() now handles allocation failures by throwing
781         OutOfMemoryErrors, its helper function allocationSize() (which computes the buffer
782         size to allocate) should also allow for allocation failure on overflow.
783
784         This issue is covered by the stress/js-fixed-array-out-of-memory.js test when
785         run on 32-bit builds.
786
787         * runtime/JSFixedArray.h:
788         (JSC::JSFixedArray::tryCreate):
789         (JSC::JSFixedArray::allocationSize):
790
791 2017-05-01  Zan Dobersek  <zdobersek@igalia.com>
792
793         [aarch64][Linux] m_allowScratchRegister assert hit in MacroAssemblerARM64 under B3::Air::CCallSpecial::generate()
794         https://bugs.webkit.org/show_bug.cgi?id=170672
795
796         Reviewed by Filip Pizlo.
797
798         In Air::CCallSpecial::admitsStack() we reject admitting the callee argument on
799         the stack for ARM64 because that can lead to disallowed usage of the scratch
800         register in MacroAssemblerARM64 when generating a call with an address Arg
801         in Air::CCallSpecial::generate().
802
803         The testLinearScanWithCalleeOnStack test is added to testb3. It reproduces the
804         original issue by force-spilling everything on the stack and enforcing the use
805         of the linear scan register allocation by using an optimization level of 1.
806
807         * b3/air/AirCCallSpecial.cpp:
808         (JSC::B3::Air::CCallSpecial::admitsStack):
809         * b3/testb3.cpp:
810         (JSC::B3::testLinearScanWithCalleeOnStack):
811         (JSC::B3::run):
812
813 2017-05-01  David Kilzer  <ddkilzer@apple.com>
814
815         Stop using sprintf() in JavaScriptCore debugger
816         <https://webkit.org/b/171512>
817
818         Reviewed by Keith Miller.
819
820         * disassembler/udis86/udis86.c:
821         (ud_insn_hex): Switch from sprintf() to snprintf().
822
823 2017-04-21  Filip Pizlo  <fpizlo@apple.com>
824
825         Air::fixObviousSpills should remove totally redundant instructions
826         https://bugs.webkit.org/show_bug.cgi?id=171131
827
828         Reviewed by Saam Barati.
829         
830         This is a modest compile-time-neutral improvement to fixObviousSpills. That phase
831         builds up a classic alias analysis data structure over spills and registers and then
832         uses it to remove the most common spill pathologies we encounter. For example, if you
833         use a spill but the spill is aliased to a register or constant, then we can replace the
834         use of the spill with a use of the register or constant.
835         
836         But that phase was missing perhaps one of the most obvious fixups that its analysis
837         allows us to do: if any instruction creates an alias we already know about, then the
838         instruction is redundant. This turned out to be super important for
839         https://bugs.webkit.org/show_bug.cgi?id=171075. That patch didn't work out, but this
840         kind of optimization might be a good clean-up for many other kinds of optimizations.
841
842         * b3/air/AirFixObviousSpills.cpp:
843
844 2017-04-30  Oleksandr Skachkov  <gskachkov@gmail.com>
845
846         We initialize functions too early in an eval
847         https://bugs.webkit.org/show_bug.cgi?id=161099
848
849         Reviewed by Saam Barati.
850
851         Current patch allow to fix problem with scope in function that is 
852         declared within eval. Before scope was set inside Interpretator.cpp and it
853         was scope where eval is executed, but in this case function would not 
854         see let/const variables and classes declated in eval.
855         This patch devide declaration and binding in two operation, first just declare
856         variable with function name, and second bind variable to function with correct 
857         scope
858
859         * bytecompiler/BytecodeGenerator.cpp:
860         (JSC::BytecodeGenerator::generate):
861         (JSC::BytecodeGenerator::BytecodeGenerator):
862         * bytecompiler/BytecodeGenerator.h:
863         * interpreter/Interpreter.cpp:
864         (JSC::Interpreter::execute):
865
866 2017-04-30  Oleksandr Skachkov  <gskachkov@gmail.com>
867
868         [ES6]. Implement Annex B.3.3 function hoisting rules for eval
869         https://bugs.webkit.org/show_bug.cgi?id=163208
870
871         Reviewed by Saam Barati.
872
873         Current patch implements Annex B.3.3 that is related to 
874         hoisting of function declaration in eval. 
875         https://tc39.github.io/ecma262/#sec-web-compat-evaldeclarationinstantiation
876         Function declaration in eval should create variable with 
877         function name in function scope where eval is invoked 
878         or bind to variable if it declared outside of the eval. 
879         If variable is created it can be removed by 'delete a;' command. 
880         If eval is invoke in block scope that contains let/const 
881         variable with the same name as function declaration 
882         we do not bind. This patch leads to the following behavior: 
883         '''
884         function foo() {
885            {
886              print(boo); // undefined
887              eval('{ function boo() {}}');
888              print(boo); // function boo() {}
889            }
890            print(boo); // function boo() {}
891         }
892
893         function foobar() {
894           { 
895             let boo = 10;
896             print(boo); // 10;
897             eval('{ function boo() {}}');
898             print(boo); // 10;
899           }
900           print(boo) // 10
901         }
902
903         function bar() {
904            {
905               var boo = 10;
906               print(boo); // 10
907               eval('{ function boo() {} }'); 
908               print(boo); // function boo() {}
909            }
910            print(boo); // function boo() {}
911         }       
912         
913         function bas() {
914             {
915                  let boo = 10;
916                  eval(' { function boo() {} } ');
917                  print(boo); // 10
918             }
919             print(boo); //Reference Error
920         }
921         '''
922
923         Current implementation relies on already implemented 
924         'hoist function in sloppy mode' feature, with small changes.
925         In short it works in following way: during hoisting of function 
926         with name S in eval, we are looking for first scope that 
927         contains space for variable with name S and if this scope 
928         has var type we bind function there
929
930         To implement this feature was added bytecode ops:
931         op_resolve_scope_for_hoisting_func_decl_in_eval - get variable scope 
932         or return undefined if variable can't be binded there.
933
934         There is a corner case, hoist function in eval within catch block,
935         that is not covered by this patch, and will be fixed in 
936         https://bugs.webkit.org/show_bug.cgi?id=168184
937
938         * bytecode/BytecodeDumper.cpp:
939         (JSC::BytecodeDumper<Block>::dumpBytecode):
940         * bytecode/BytecodeList.json:
941         * bytecode/BytecodeUseDef.h:
942         (JSC::computeUsesForBytecodeOffset):
943         (JSC::computeDefsForBytecodeOffset):
944         * bytecode/CodeBlock.cpp:
945         (JSC::CodeBlock::finalizeLLIntInlineCaches):
946         * bytecode/EvalCodeBlock.h:
947         (JSC::EvalCodeBlock::functionHoistingCandidate):
948         (JSC::EvalCodeBlock::numFunctionHoistingCandidates):
949         * bytecode/UnlinkedEvalCodeBlock.h:
950         * bytecompiler/BytecodeGenerator.cpp:
951         (JSC::BytecodeGenerator::BytecodeGenerator):
952         (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
953         (JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval):
954         * bytecompiler/BytecodeGenerator.h:
955         * dfg/DFGAbstractInterpreterInlines.h:
956         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
957         * dfg/DFGByteCodeParser.cpp:
958         (JSC::DFG::ByteCodeParser::parseBlock):
959         * dfg/DFGCapabilities.cpp:
960         (JSC::DFG::capabilityLevel):
961         * dfg/DFGClobberize.h:
962         (JSC::DFG::clobberize):
963         * dfg/DFGDoesGC.cpp:
964         (JSC::DFG::doesGC):
965         * dfg/DFGFixupPhase.cpp:
966         (JSC::DFG::FixupPhase::fixupNode):
967         * dfg/DFGNode.h:
968         (JSC::DFG::Node::hasIdentifier):
969         * dfg/DFGNodeType.h:
970         * dfg/DFGOperations.cpp:
971         * dfg/DFGOperations.h:
972         * dfg/DFGPredictionPropagationPhase.cpp:
973         * dfg/DFGSafeToExecute.h:
974         (JSC::DFG::safeToExecute):
975         * dfg/DFGSpeculativeJIT.cpp:
976         (JSC::DFG::SpeculativeJIT::compileResolveScopeForHoistingFuncDeclInEval):
977         * dfg/DFGSpeculativeJIT.h:
978         (JSC::DFG::SpeculativeJIT::callOperation):
979         * dfg/DFGSpeculativeJIT32_64.cpp:
980         (JSC::DFG::SpeculativeJIT::compile):
981         * dfg/DFGSpeculativeJIT64.cpp:
982         (JSC::DFG::SpeculativeJIT::compile):
983         * ftl/FTLCapabilities.cpp:
984         (JSC::FTL::canCompile):
985         * ftl/FTLLowerDFGToB3.cpp:
986         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
987         (JSC::FTL::DFG::LowerDFGToB3::compileResolveScopeForHoistingFuncDeclInEval):
988         * interpreter/Interpreter.cpp:
989         (JSC::Interpreter::execute):
990         * jit/JIT.cpp:
991         (JSC::JIT::privateCompileMainPass):
992         * jit/JIT.h:
993         * jit/JITOperations.h:
994         * jit/JITPropertyAccess.cpp:
995         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
996         * jit/JITPropertyAccess32_64.cpp:
997         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
998         * llint/LowLevelInterpreter.asm:
999         * parser/Parser.cpp:
1000         (JSC::Parser<LexerType>::parseFunctionDeclarationStatement):
1001         * parser/Parser.h:
1002         (JSC::Scope::getSloppyModeHoistedFunctions):
1003         (JSC::Parser::declareFunction):
1004         * runtime/CommonSlowPaths.cpp:
1005         (JSC::SLOW_PATH_DECL):
1006         * runtime/CommonSlowPaths.h:
1007         * runtime/EvalExecutable.h:
1008         (JSC::EvalExecutable::numFunctionHoistingCandidates):
1009         (JSC::EvalExecutable::numTopLevelFunctionDecls):
1010         (JSC::EvalExecutable::numberOfFunctionDecls): Deleted.
1011         * runtime/JSScope.cpp:
1012         (JSC::JSScope::resolve):
1013         (JSC::JSScope::resolveScopeForHoistingFuncDeclInEval):
1014         * runtime/JSScope.h:
1015
1016 2017-04-29  Oleksandr Skachkov  <gskachkov@gmail.com>
1017
1018         Deep nesting is leading to ReferenceError for hoisted function
1019         https://bugs.webkit.org/show_bug.cgi?id=171456
1020
1021         Reviewed by Yusuke Suzuki.
1022
1023         Current patch fix error that appears during hoisting of the function 
1024         in block scope. Error happens only when exist some deep scope that lead
1025         to increase scope stack, after which list of the hosted candidates do not 
1026         copied to updated scope stack.
1027
1028         * parser/Parser.h:
1029         (JSC::Scope::Scope):
1030
1031 2017-04-29  Yusuke Suzuki  <utatane.tea@gmail.com>
1032
1033         [JSC] LabelScopePtr is not necessary
1034         https://bugs.webkit.org/show_bug.cgi?id=171474
1035
1036         Reviewed by Geoffrey Garen.
1037
1038         Originally, LabelScopePtr is introduced because LabelScopes uses Vector<> instead of SegmentedVector<>.
1039         LabelScopePtr holds the pointer to the vector owner and index instead of the pointer to LabelScope directly
1040         since Vector<> can relocate LocalScopes inside it.
1041         The reason why LabelScopes use Vector instead is that there is code copying this vector. SegmentedVector<>
1042         prohibits copying since it is so costly. So, we used Vector<> here instead of SegmentedVector<>.
1043
1044         But the latest code does not have copying code for LabelScopes. Thus, we can take the same design to Label and
1045         RegisterID. Just use SegmentedVector<> and Ref<>/RefPtr<>. This patch removes LabelScopePtr since it is no
1046         longer necessary. And use SegmentedVector for LabelScopes.
1047
1048         * bytecompiler/BytecodeGenerator.cpp:
1049         (JSC::reclaim):
1050         (JSC::BytecodeGenerator::reclaimFreeRegisters):
1051         (JSC::BytecodeGenerator::newLabelScope):
1052         (JSC::BytecodeGenerator::newLabel):
1053         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
1054         (JSC::BytecodeGenerator::breakTarget):
1055         (JSC::BytecodeGenerator::continueTarget):
1056         (JSC::BytecodeGenerator::emitEnumeration):
1057         * bytecompiler/BytecodeGenerator.h:
1058         * bytecompiler/LabelScope.h:
1059         (JSC::LabelScope::LabelScope):
1060         (JSC::LabelScope::breakTarget):
1061         (JSC::LabelScope::continueTarget):
1062         (JSC::LabelScope::type):
1063         (JSC::LabelScope::name):
1064         (JSC::LabelScope::scopeDepth):
1065         (JSC::LabelScope::ref):
1066         (JSC::LabelScope::deref):
1067         (JSC::LabelScope::refCount):
1068         (JSC::LabelScopePtr::LabelScopePtr): Deleted.
1069         (JSC::LabelScopePtr::operator=): Deleted.
1070         (JSC::LabelScopePtr::~LabelScopePtr): Deleted.
1071         (JSC::LabelScopePtr::operator!): Deleted.
1072         (JSC::LabelScopePtr::operator*): Deleted.
1073         (JSC::LabelScopePtr::operator->): Deleted.
1074         (JSC::LabelScopePtr::null): Deleted.
1075         * bytecompiler/NodesCodegen.cpp:
1076         (JSC::DoWhileNode::emitBytecode):
1077         (JSC::WhileNode::emitBytecode):
1078         (JSC::ForNode::emitBytecode):
1079         (JSC::ForInNode::emitBytecode):
1080         (JSC::ContinueNode::trivialTarget):
1081         (JSC::ContinueNode::emitBytecode):
1082         (JSC::BreakNode::trivialTarget):
1083         (JSC::BreakNode::emitBytecode):
1084         (JSC::SwitchNode::emitBytecode):
1085         (JSC::LabelNode::emitBytecode):
1086
1087 2017-04-28  Mark Lam  <mark.lam@apple.com>
1088
1089         Revert instrumentation from https://bugs.webkit.org/show_bug.cgi?id=170086 that is no longer needed.
1090         https://bugs.webkit.org/show_bug.cgi?id=170094
1091
1092         Reviewed by JF Bastien and Keith Miller.
1093
1094         * heap/Heap.cpp:
1095         (JSC::Heap::resumeThePeriphery):
1096
1097 2017-04-27  Andy VanWagoner  <thetalecrafter@gmail.com>
1098
1099         [INTL] Implement the caseFirst option for Intl.Collator
1100         https://bugs.webkit.org/show_bug.cgi?id=158188
1101
1102         Reviewed by Geoffrey Garen.
1103
1104         Implements the caseFirst option and unicode locale extension.
1105         The caseFirst option explicitly determines whether upper or lower case comes first.
1106
1107         * runtime/IntlCollator.cpp:
1108         (JSC::sortLocaleData): Added kf data.
1109         (JSC::searchLocaleData): Added kf data.
1110         (JSC::IntlCollator::initializeCollator): Set caseFirst option.
1111         (JSC::IntlCollator::createCollator): Set new attributes on ICU collator.
1112         (JSC::IntlCollator::caseFirstString): Added.
1113         (JSC::IntlCollator::resolvedOptions): Added caseFirst property.
1114         * runtime/IntlCollator.h:
1115
1116 2017-04-27  Mark Lam  <mark.lam@apple.com>
1117
1118         Fix some RELEASE_ASSERT failures caused by OutOfMemoryErrors.
1119         https://bugs.webkit.org/show_bug.cgi?id=171404
1120         <rdar://problem/31876178>
1121
1122         Reviewed by Saam Barati.
1123
1124         1. Added some tryAllocate() functions in JSCellInlines.h.
1125         2. Consolidated the implementations of allocateCell() template functions into a
1126            single tryAllocateCellHelper() to reduce redundancy and eliminate needing to
1127            copy-paste for variations of allocateCell and tryAllocateCell.
1128         3. Changed JSFixedArray::createFromArray() and constructEmptyArray() to check for
1129            allocation failure and throw an OutOfMemoryError.  It was already possible to
1130            throw errors from these functions for other reasons.  So, their clients are
1131            already ready to handle OOMEs.
1132
1133         * ftl/FTLOperations.cpp:
1134         (JSC::FTL::operationMaterializeObjectInOSR):
1135         * runtime/JSCInlines.h:
1136         * runtime/JSCell.h:
1137         * runtime/JSCellInlines.h:
1138         (JSC::tryAllocateCellHelper):
1139         (JSC::allocateCell):
1140         (JSC::tryAllocateCell):
1141         * runtime/JSFixedArray.h:
1142         (JSC::JSFixedArray::createFromArray):
1143         (JSC::JSFixedArray::tryCreate):
1144         (JSC::JSFixedArray::create): Deleted.
1145         * runtime/JSGlobalObject.h:
1146         (JSC::constructEmptyArray):
1147
1148 2017-04-27  Joseph Pecoraro  <pecoraro@apple.com>
1149
1150         Support for promise rejection events (unhandledrejection)
1151         https://bugs.webkit.org/show_bug.cgi?id=150358
1152         <rdar://problem/28441651>
1153
1154         Reviewed by Saam Barati.
1155
1156         Patch by Joseph Pecoraro and Yusuke Suzuki.
1157
1158         Implement support for promise.[[PromiseIsHandled]] and the
1159         HostPromiseRejectionTracker hook for HTML to track promise rejections:
1160         https://tc39.github.io/ecma262/#sec-host-promise-rejection-tracker
1161         https://html.spec.whatwg.org/multipage/webappapis.html#unhandled-promise-rejections
1162
1163         * builtins/BuiltinNames.h:
1164         New private symbols.
1165
1166         * builtins/PromiseOperations.js:
1167         (globalPrivate.newHandledRejectedPromise):
1168         Utility to create a rejected promise with [[PromiseIsHandled]] to true.
1169
1170         (globalPrivate.rejectPromise):
1171         (globalPrivate.initializePromise):
1172         * builtins/PromisePrototype.js:
1173         (then):
1174         Implement standard behavior of [[PromiseIsHandled]] and the host hook.
1175
1176         * runtime/JSPromise.cpp:
1177         (JSC::JSPromise::isHandled):
1178         * runtime/JSPromise.h:
1179         C++ accessors for the [[PromiseIsHandled]] state.
1180
1181         * bytecode/BytecodeIntrinsicRegistry.cpp:
1182         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
1183         * bytecode/BytecodeIntrinsicRegistry.h:
1184         Expose private values for the Reject / Handle enum values in built-ins.
1185
1186         * jsc.cpp:
1187         * runtime/JSGlobalObject.h:
1188         (JSC::JSGlobalObject::promiseResolveFunction):
1189         Add a new GlobalObjectMethodTable hook matching the promise rejection hook.
1190
1191         * runtime/JSGlobalObject.cpp:
1192         (JSC::JSGlobalObject::init):
1193         (JSC::JSGlobalObject::visitChildren):
1194         * runtime/JSGlobalObjectFunctions.cpp:
1195         (JSC::globalFuncHostPromiseRejectionTracker):
1196         * runtime/JSGlobalObjectFunctions.h:
1197         Plumb the builtin hook through to the optional GlobalObjectMethodTable hook.
1198
1199         * inspector/InjectedScriptSource.js:
1200         (InjectedScript.prototype.createFakeValueDescriptor):
1201         Silence possible rejected promises created internally via Web Inspector.
1202
1203 2017-04-27  Saam Barati  <sbarati@apple.com>
1204
1205         B3::FoldPathConstants does not consider the fall through case for Switch
1206         https://bugs.webkit.org/show_bug.cgi?id=171390
1207
1208         Reviewed by Filip Pizlo.
1209
1210         foldPathConstants was not taking into account a Switch's default
1211         case when it tried to constant propagate the switch's operand value.
1212         e.g, we incorrectly transformed this code:
1213         
1214         ```
1215         x = argumentGPR0;
1216         switch (x) {
1217         case 10: return 20;
1218         
1219         case 0:
1220         default: return x == 0;
1221         }
1222         ```
1223         
1224         into:
1225         ```
1226         x = argumentGPR0;
1227         switch (x) {
1228         case 10: return 20;
1229         
1230         case 0:
1231         default: return 1;
1232         }
1233         ```
1234         
1235         Because we didn't take into account the default case, we incorrectly
1236         optimized the code as if case 0's block was only reachable if x is
1237         equal to zero. This is obviously not true, since it's the same block
1238         as the default case.
1239         
1240         This fix ensures that we can run the WebAssembly Tanks demo even when
1241         we set webAssemblyBBQOptimizationLevel=2.
1242
1243         * b3/B3FoldPathConstants.cpp:
1244         * b3/B3SwitchValue.cpp:
1245         (JSC::B3::SwitchValue::fallThrough):
1246         (JSC::B3::SwitchValue::removeCase): Deleted.
1247         * b3/B3SwitchValue.h:
1248         * b3/testb3.cpp:
1249         (JSC::B3::testCallFunctionWithHellaArguments):
1250         (JSC::B3::testSwitchSameCaseAsDefault):
1251         (JSC::B3::testWasmBoundsCheck):
1252         (JSC::B3::run):
1253
1254 2017-04-27  Keith Miller  <keith_miller@apple.com>
1255
1256         WebAssembly: Don't tier up the same function twice
1257         https://bugs.webkit.org/show_bug.cgi?id=171397
1258
1259         Reviewed by Filip Pizlo.
1260
1261         Because we don't CAS the tier up count on function entry/loop backedge and we use the least significant to indicate whether or not tier up has already started we could see the following:
1262
1263         Threads A and B are running count in memory is (0):
1264
1265         A: load tier up count (0)
1266         B: load tier up count (0)
1267         A: decrement count to -2 and see we need to check for tier up (0)
1268         A: store -2 to count (-2)
1269         A: exchangeOr(1) to tier up count (-1)
1270         B: decrement count to -2 and see we need to check for tier up (-1)
1271         B: store -2 to count (-2)
1272         B: exchangeOr(1) to tier up count (-1)
1273
1274         This would cause us to tier up the same function twice, which we would rather avoid.
1275
1276         * wasm/WasmB3IRGenerator.cpp:
1277         (JSC::Wasm::B3IRGenerator::emitTierUpCheck):
1278         * wasm/WasmTierUpCount.h:
1279         (JSC::Wasm::TierUpCount::TierUpCount):
1280         (JSC::Wasm::TierUpCount::loopDecrement):
1281         (JSC::Wasm::TierUpCount::functionEntryDecrement):
1282         (JSC::Wasm::TierUpCount::shouldStartTierUp):
1283
1284 2017-04-27  Keith Miller  <keith_miller@apple.com>
1285
1286         REGRESSION (r215843): ASSERTION FAILED: !m_completionTasks[0].first in  JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast(JSC::VM &)
1287         https://bugs.webkit.org/show_bug.cgi?id=171380
1288
1289         Reviewed by JF Bastien.
1290
1291         This patch fixes the association of VMs to Wasm::Plans. For validation
1292         we want all the completion tasks to be associate with a VM. For BBQ,
1293         we want the main task to not be associated with any VM.
1294
1295         * jsc.cpp:
1296         (functionTestWasmModuleFunctions):
1297         * wasm/WasmBBQPlan.cpp:
1298         (JSC::Wasm::BBQPlan::BBQPlan):
1299         * wasm/WasmBBQPlan.h:
1300         * wasm/WasmCodeBlock.cpp:
1301         (JSC::Wasm::CodeBlock::CodeBlock):
1302         (JSC::Wasm::CodeBlock::compileAsync):
1303         * wasm/WasmCodeBlock.h:
1304         (JSC::Wasm::CodeBlock::create):
1305         * wasm/WasmModule.cpp:
1306         (JSC::Wasm::makeValidationCallback):
1307         (JSC::Wasm::Module::validateSync):
1308         (JSC::Wasm::Module::validateAsync):
1309         (JSC::Wasm::Module::getOrCreateCodeBlock):
1310         (JSC::Wasm::Module::compileSync):
1311         (JSC::Wasm::Module::compileAsync):
1312         * wasm/WasmModule.h:
1313         * wasm/WasmOMGPlan.cpp:
1314         (JSC::Wasm::OMGPlan::OMGPlan):
1315         (JSC::Wasm::runOMGPlanForIndex):
1316         * wasm/WasmOMGPlan.h:
1317         * wasm/WasmPlan.cpp:
1318         (JSC::Wasm::Plan::Plan):
1319         (JSC::Wasm::Plan::runCompletionTasks):
1320         (JSC::Wasm::Plan::addCompletionTask):
1321         (JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast):
1322         * wasm/WasmPlan.h:
1323         (JSC::Wasm::Plan::dontFinalize):
1324         * wasm/js/WebAssemblyInstanceConstructor.cpp:
1325         (JSC::constructJSWebAssemblyInstance):
1326         * wasm/js/WebAssemblyPrototype.cpp:
1327         (JSC::webAssemblyValidateFunc):
1328
1329 2017-04-27  Saam Barati  <sbarati@apple.com>
1330
1331         Restore some caching functionality that got accidentally removed when doing Wasm PIC patches
1332         https://bugs.webkit.org/show_bug.cgi?id=171382
1333
1334         Reviewed by Keith Miller.
1335
1336         When I created Wasm::CodeBlock, I accidentally removed caching
1337         the creation of JSWebAssemblyCodeBlocks. This patch restores it.
1338         It's worth keeping JSWebAssemblyModule's JSWebAssemblyCodeBlock
1339         cache because creating a JSWebAssemblyCodeBlock does non trivial
1340         work by creating the various IC call stubs.
1341
1342         * wasm/js/JSWebAssemblyCodeBlock.h:
1343         (JSC::JSWebAssemblyCodeBlock::codeBlock):
1344         * wasm/js/JSWebAssemblyInstance.cpp:
1345         (JSC::JSWebAssemblyInstance::finalizeCreation):
1346         (JSC::JSWebAssemblyInstance::create):
1347         * wasm/js/JSWebAssemblyModule.h:
1348
1349 2017-04-27  Mark Lam  <mark.lam@apple.com>
1350
1351         Audit and fix incorrect uses of JSArray::tryCreateForInitializationPrivate().
1352         https://bugs.webkit.org/show_bug.cgi?id=171344
1353         <rdar://problem/31352667>
1354
1355         Reviewed by Filip Pizlo.
1356
1357         JSArray::tryCreateForInitializationPrivate() should only be used in performance
1358         critical paths, and should always be used with care because it creates an
1359         uninitialized object that needs to be initialized by its client before the object
1360         can be released into the system.  Before the object is fully initialized:
1361         a. the client should not re-enter the VM to execute JS code, and
1362         b. GC should not run.
1363
1364         This is because until the object is fully initialized, it is an inconsistent
1365         state that the GC and JS code will not be happy about.
1366
1367         In this patch, we do the following:
1368
1369         1. Renamed JSArray::tryCreateForInitializationPrivate() to
1370            JSArray::tryCreateUninitializedRestricted() because "private" is a bit ambiguous
1371            and can be confused with APIs that are called freely within WebKit but are
1372            not meant for clients of WebKit.  In this case, we intend for use of this API
1373            to be restricted to only a few carefully considered and crafted cases.
1374
1375         2. Introduce the ObjectInitializationScope RAII object which covers the period
1376            when the uninitialized object is created and gets initialized.
1377
1378            ObjectInitializationScope will asserts that either the object is created
1379            fully initialized (in the case where the object structure is not an "original"
1380            structure) or if created uninitialized, is fully initialized at the end of
1381            the scope.
1382
1383            If the object is created uninitialized, the ObjectInitializationScope also
1384            ensures that we do not GC nor re-enter the VM to execute JS code.  This is
1385            achieved by enabling DisallowGC and DisallowVMReentry scopes.
1386
1387            tryCreateUninitializedRestricted() and initializeIndex() now requires an
1388            ObjectInitializationScope instance.  The ObjectInitializationScope replaces
1389            the VM& argument because it can be used to pass the VM& itself.  This is a
1390            small optimization that makes passing the ObjectInitializationScope free even
1391            on release builds.
1392
1393         3. Factored a DisallowScope out of DisallowGC, and make DisallowGC extend it.
1394            Introduce a DisallowVMReentry class that extends DisallowScope.
1395
1396         4. Fixed a bug found by the ObjectInitializationScope.  The bug is that there are
1397            scenarios where the structure passed to tryCreateUninitializedRestricted()
1398            that may not be an "original" structure.  As a result, initializeIndex() would
1399            end up allocating new structures, and therefore trigger a GC.
1400
1401            The fix is to detect that the structure passed to tryCreateUninitializedRestricted()
1402            is not an "original" one, and pre-initialize the array with 0s.
1403
1404            This bug was detected by existing tests. Hence, no new test needed.
1405
1406         5. Replaced all inappropriate uses of tryCreateUninitializedRestricted() with
1407            tryCreate().  Inappropriate uses here means code that is not in performance
1408            critical paths.
1409
1410            Similarly, replaced accompanying uses of initializeIndex() with putDirectIndex().
1411
1412            This patch is performance neutral (according to the JSC command line benchmarks).
1413
1414         * CMakeLists.txt:
1415         * JavaScriptCore.xcodeproj/project.pbxproj:
1416         * dfg/DFGOperations.cpp:
1417         * ftl/FTLOperations.cpp:
1418         (JSC::FTL::operationMaterializeObjectInOSR):
1419         * heap/DeferGC.cpp:
1420         * heap/DeferGC.h:
1421         (JSC::DisallowGC::DisallowGC):
1422         (JSC::DisallowGC::initialize):
1423         (JSC::DisallowGC::scopeReentryCount):
1424         (JSC::DisallowGC::setScopeReentryCount):
1425         (JSC::DisallowGC::~DisallowGC): Deleted.
1426         (JSC::DisallowGC::isGCDisallowedOnCurrentThread): Deleted.
1427         * heap/GCDeferralContextInlines.h:
1428         (JSC::GCDeferralContext::~GCDeferralContext):
1429         * heap/Heap.cpp:
1430         (JSC::Heap::collectIfNecessaryOrDefer):
1431         * runtime/ArrayPrototype.cpp:
1432         (JSC::arrayProtoPrivateFuncConcatMemcpy):
1433         * runtime/ClonedArguments.cpp:
1434         (JSC::ClonedArguments::createWithInlineFrame):
1435         (JSC::ClonedArguments::createByCopyingFrom):
1436         * runtime/CommonSlowPaths.cpp:
1437         (JSC::SLOW_PATH_DECL):
1438         * runtime/DisallowScope.h: Added.
1439         (JSC::DisallowScope::DisallowScope):
1440         (JSC::DisallowScope::~DisallowScope):
1441         (JSC::DisallowScope::isInEffectOnCurrentThread):
1442         (JSC::DisallowScope::enable):
1443         (JSC::DisallowScope::enterScope):
1444         (JSC::DisallowScope::exitScope):
1445         * runtime/DisallowVMReentry.cpp: Added.
1446         * runtime/DisallowVMReentry.h: Added.
1447         (JSC::DisallowVMReentry::DisallowVMReentry):
1448         (JSC::DisallowVMReentry::initialize):
1449         (JSC::DisallowVMReentry::scopeReentryCount):
1450         (JSC::DisallowVMReentry::setScopeReentryCount):
1451         * runtime/InitializeThreading.cpp:
1452         (JSC::initializeThreading):
1453         * runtime/JSArray.cpp:
1454         (JSC::JSArray::tryCreateUninitializedRestricted):
1455         (JSC::JSArray::fastSlice):
1456         (JSC::JSArray::tryCreateForInitializationPrivate): Deleted.
1457         * runtime/JSArray.h:
1458         (JSC::JSArray::tryCreateUninitializedRestricted):
1459         (JSC::JSArray::tryCreate):
1460         (JSC::constructArray):
1461         (JSC::constructArrayNegativeIndexed):
1462         (JSC::JSArray::tryCreateForInitializationPrivate): Deleted.
1463         (JSC::createArrayButterfly): Deleted.
1464         * runtime/JSCellInlines.h:
1465         (JSC::allocateCell):
1466         * runtime/JSObject.h:
1467         (JSC::JSObject::initializeIndex):
1468         (JSC::JSObject::initializeIndexWithoutBarrier):
1469         * runtime/ObjectInitializationScope.cpp: Added.
1470         (JSC::ObjectInitializationScope::ObjectInitializationScope):
1471         (JSC::ObjectInitializationScope::~ObjectInitializationScope):
1472         (JSC::ObjectInitializationScope::notifyAllocated):
1473         (JSC::ObjectInitializationScope::verifyPropertiesAreInitialized):
1474         * runtime/ObjectInitializationScope.h: Added.
1475         (JSC::ObjectInitializationScope::ObjectInitializationScope):
1476         (JSC::ObjectInitializationScope::vm):
1477         (JSC::ObjectInitializationScope::notifyAllocated):
1478         * runtime/Operations.h:
1479         (JSC::isScribbledValue):
1480         (JSC::scribble):
1481         * runtime/RegExpMatchesArray.cpp:
1482         (JSC::createEmptyRegExpMatchesArray):
1483         * runtime/RegExpMatchesArray.h:
1484         (JSC::tryCreateUninitializedRegExpMatchesArray):
1485         (JSC::createRegExpMatchesArray):
1486         * runtime/VMEntryScope.cpp:
1487         (JSC::VMEntryScope::VMEntryScope):
1488
1489 2017-04-27  Carlos Garcia Campos  <cgarcia@igalia.com>
1490
1491         [GTK] Remote inspector should support inspecting targets with previous version of backend commands
1492         https://bugs.webkit.org/show_bug.cgi?id=171267
1493
1494         Reviewed by Michael Catanzaro.
1495
1496         Rename GetTargetList DBus method as SetupInspectorClient since this method is actually called only once by
1497         client right after connecting to the server. The method now receives the client backend commands hash as
1498         argument and returns the contents of the backend commands file in case the hash doesn't match with the local
1499         version.
1500
1501         * PlatformGTK.cmake: Add RemoteInspectorUtils to compilation.
1502         * inspector/remote/glib/RemoteInspectorServer.cpp:
1503         (Inspector::RemoteInspectorServer::setupInspectorClient):
1504         * inspector/remote/glib/RemoteInspectorServer.h:
1505         * inspector/remote/glib/RemoteInspectorUtils.cpp: Added.
1506         (Inspector::backendCommands):
1507         (Inspector::backendCommandsHash):
1508         * inspector/remote/glib/RemoteInspectorUtils.h: Added.
1509
1510 2017-04-27  Yusuke Suzuki  <utatane.tea@gmail.com>
1511
1512         [JSC] Handle PhantomSpread in LoadVarargs as the same to the others
1513         https://bugs.webkit.org/show_bug.cgi?id=171262
1514
1515         Reviewed by Saam Barati.
1516
1517         This is follow-up patch after r215720. In that patch, accidentally
1518         we did not apply the same change to LoadVarargs in argument elimination
1519         phase. This patch just does the same rewriting to handle PhantomSpread
1520         correctly.
1521
1522         * dfg/DFGArgumentsEliminationPhase.cpp:
1523
1524 2017-04-26  Joseph Pecoraro  <pecoraro@apple.com>
1525
1526         Web Inspector: Uint8ClampedArray should be treated like an array, not an object
1527         https://bugs.webkit.org/show_bug.cgi?id=171364
1528         <rdar://problem/10873037>
1529
1530         Reviewed by Sam Weinig.
1531
1532         * inspector/JSInjectedScriptHost.cpp:
1533         (Inspector::JSInjectedScriptHost::subtype):
1534         Treat Uint8ClampedArray (like other Typed Arrays) as an array.
1535
1536 2017-04-26  Saam Barati  <sbarati@apple.com>
1537
1538         Print Wasm function index in stack trace
1539         https://bugs.webkit.org/show_bug.cgi?id=171349
1540
1541         Reviewed by JF Bastien.
1542
1543         This patch prints a Callee's index in the function index
1544         space in Error.stack.
1545
1546         This will lead to stack traces that have lines of text like:
1547         wasm function index: 4@[wasm code]
1548
1549         We don't ascribe indices to everything in wasm. Specifically, the
1550         Wasm->JS call stub callee does not get a name, and neither does
1551         the JS -> Wasm entrypoint.
1552
1553         * interpreter/Interpreter.cpp:
1554         (JSC::GetStackTraceFunctor::operator()):
1555         * interpreter/StackVisitor.cpp:
1556         (JSC::StackVisitor::readNonInlinedFrame):
1557         (JSC::StackVisitor::Frame::functionName):
1558         * interpreter/StackVisitor.h:
1559         (JSC::StackVisitor::Frame::wasmFunctionIndex):
1560         * runtime/StackFrame.cpp:
1561         (JSC::StackFrame::functionName):
1562         * runtime/StackFrame.h:
1563         (JSC::StackFrame::StackFrame):
1564         (JSC::StackFrame::wasm):
1565         (JSC::StackFrame::hasBytecodeOffset):
1566         (JSC::StackFrame::bytecodeOffset):
1567         * wasm/WasmBBQPlanInlines.h:
1568         (JSC::Wasm::BBQPlan::initializeCallees):
1569         * wasm/WasmCallee.cpp:
1570         (JSC::Wasm::Callee::Callee):
1571         * wasm/WasmCallee.h:
1572         (JSC::Wasm::Callee::create):
1573         (JSC::Wasm::Callee::index):
1574         * wasm/WasmOMGPlan.cpp:
1575         (JSC::Wasm::OMGPlan::work):
1576
1577 2017-04-26  Keith Miller  <keith_miller@apple.com>
1578
1579         Follow up to r215843
1580         https://bugs.webkit.org/show_bug.cgi?id=171361
1581
1582         Reviewed by Saam Barati.
1583
1584         This patch fixes some style comments Saam didn't get a chance to
1585         request before I landed: https://bugs.webkit.org/show_bug.cgi?id=170134.
1586
1587         It renames Wasm::CodeBlock::m_wasmEntrypoints to
1588         m_wasmIndirectCallEntrypoints, as well as fixes some copyrights and
1589         indentation.
1590
1591         * wasm/WasmBBQPlan.cpp:
1592         * wasm/WasmCodeBlock.cpp:
1593         (JSC::Wasm::CodeBlock::CodeBlock):
1594         * wasm/WasmCodeBlock.h:
1595         (JSC::Wasm::CodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace):
1596         * wasm/WasmOMGPlan.cpp:
1597         (JSC::Wasm::OMGPlan::work):
1598         * wasm/WasmTierUpCount.h:
1599         (JSC::Wasm::TierUpCount::TierUpCount):
1600         (JSC::Wasm::TierUpCount::loopDecrement):
1601         (JSC::Wasm::TierUpCount::functionEntryDecrement):
1602         (JSC::Wasm::TierUpCount::shouldStartTierUp):
1603         (JSC::Wasm::TierUpCount::count):
1604
1605 2017-04-26  Saam Barati  <sbarati@apple.com>
1606
1607         ASSERTION FAILED: inIndex != notFound in JSC::invalidParameterInSourceAppender()
1608         https://bugs.webkit.org/show_bug.cgi?id=170924
1609         <rdar://problem/31721052>
1610
1611         Reviewed by Mark Lam.
1612
1613         The error message handler for "in" was searching for the literal
1614         string "in". However, our parser incorrectly allows escaped characters
1615         to be part of keywords. So this is parsed as "in" in JSC: "i\u006E".
1616         It should not be parsed that way. I opened https://bugs.webkit.org/show_bug.cgi?id=171310
1617         to address this issue.
1618         
1619         Regardless, the error message handlers should handle unexpected text gracefully.
1620         All functions that try to augment error messages with the goal of
1621         providing a more textual context for the error message should use
1622         the original error message instead of crashing when they detect
1623         unexpected text.
1624         
1625         This patch also changes the already buggy code that tries to find
1626         the base of a function call. That could would fail for code like this:
1627         "zoo.bar("/abc\)*/");". See https://bugs.webkit.org/show_bug.cgi?id=146304
1628         It would think that the base is "z". However, the algorithm that tries
1629         to find the base can often tell when it fails, and when it does, it should
1630         happily return the approximate text error message instead of thinking
1631         that the base is "z".
1632
1633         * runtime/ExceptionHelpers.cpp:
1634         (JSC::functionCallBase):
1635         (JSC::notAFunctionSourceAppender):
1636         (JSC::invalidParameterInSourceAppender):
1637
1638 2017-04-26  Keith Miller  <keith_miller@apple.com>
1639
1640         WebAssembly: Implement tier up
1641         https://bugs.webkit.org/show_bug.cgi?id=170134
1642
1643         Reviewed by Filip Pizlo.
1644
1645         This patch implements tier up for wasm functions. Unlike with JS
1646         code, wasm code needs to be able to tier up concurrently with the
1647         running code.  Since JS code is synchronous we can always link on
1648         the running thread, wasm, however, can run the same code on more
1649         than one thread. In order to make patching work correctly, we need
1650         to ensure that all patches of callsites are aligned. On ARM we get
1651         this for free since every call is a near call. On X86 we ensure
1652         that the 32-bit relative offset is 32-bit aligned.
1653
1654         This patch also modifies how Wasm::Plan works. Now Plan is a
1655         abstract super class and there are two subclasses, which
1656         correspond to the different tiers of our wasm engine.  The first,
1657         Build Bytecode Quickly (BBQ) tier, roughly does what the old plan
1658         code did before.  The new tier, Optimized Machine code Generation
1659         (OMG), can be called at any point by BBQ code and compiles exactly
1660         one function. Once an OMGPlan finishes it will link it's code
1661         internally then reset the instruction cache of all running wasm
1662         threads, via, a ThreadMessage. Once the instruction caches have
1663         been reset all the other functions will be patched to call the new
1664         code.
1665
1666         * JavaScriptCore.xcodeproj/project.pbxproj:
1667         * assembler/AbstractMacroAssembler.h:
1668         (JSC::AbstractMacroAssembler::ensureCacheLineSpace):
1669         * assembler/CodeLocation.h:
1670         (JSC::CodeLocationThreadSafeNearCall::CodeLocationThreadSafeNearCall):
1671         * assembler/MacroAssemblerARM64.h:
1672         (JSC::MacroAssemblerARM64::threadSafePatchableNearCall):
1673         * assembler/MacroAssemblerX86Common.h:
1674         (JSC::MacroAssemblerX86Common::threadSafeNearCall):
1675         * assembler/MacroAssemblerX86_64.h:
1676         (JSC::MacroAssemblerX86_64::threadSafePatchableNearCall):
1677         * b3/air/AirEmitShuffle.cpp:
1678         (JSC::B3::Air::ShufflePair::inst):
1679         (JSC::B3::Air::ShufflePair::opcode): Deleted.
1680         * b3/air/AirEmitShuffle.h:
1681         * jsc.cpp:
1682         (functionTestWasmModuleFunctions):
1683         * runtime/JSLock.cpp:
1684         (JSC::JSLock::didAcquireLock):
1685         * runtime/Options.h:
1686         * wasm/WasmB3IRGenerator.cpp:
1687         (JSC::Wasm::B3IRGenerator::materializeWasmContext):
1688         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1689         (JSC::Wasm::B3IRGenerator::constant):
1690         (JSC::Wasm::B3IRGenerator::emitTierUpCheck):
1691         (JSC::Wasm::B3IRGenerator::addLoop):
1692         (JSC::Wasm::B3IRGenerator::addTopLevel):
1693         (JSC::Wasm::B3IRGenerator::addBlock):
1694         (JSC::Wasm::createJSToWasmWrapper):
1695         (JSC::Wasm::parseAndCompile):
1696         * wasm/WasmB3IRGenerator.h:
1697         * wasm/WasmBBQPlan.cpp: Copied from Source/JavaScriptCore/wasm/WasmPlan.cpp.
1698         (JSC::Wasm::BBQPlan::BBQPlan):
1699         (JSC::Wasm::BBQPlan::stateString):
1700         (JSC::Wasm::BBQPlan::moveToState):
1701         (JSC::Wasm::BBQPlan::parseAndValidateModule):
1702         (JSC::Wasm::BBQPlan::prepare):
1703         (JSC::Wasm::BBQPlan::ThreadCountHolder::ThreadCountHolder):
1704         (JSC::Wasm::BBQPlan::ThreadCountHolder::~ThreadCountHolder):
1705         (JSC::Wasm::BBQPlan::compileFunctions):
1706         (JSC::Wasm::BBQPlan::complete):
1707         (JSC::Wasm::BBQPlan::work):
1708         * wasm/WasmBBQPlan.h: Copied from Source/JavaScriptCore/wasm/WasmPlan.h.
1709         * wasm/WasmBBQPlanInlines.h: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h.
1710         (JSC::Wasm::BBQPlan::initializeCallees):
1711         * wasm/WasmBinding.cpp:
1712         (JSC::Wasm::wasmToWasm):
1713         * wasm/WasmCallee.h:
1714         (JSC::Wasm::Callee::entrypoint):
1715         * wasm/WasmCodeBlock.cpp:
1716         (JSC::Wasm::CodeBlock::CodeBlock):
1717         * wasm/WasmCodeBlock.h:
1718         (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
1719         (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
1720         (JSC::Wasm::CodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace):
1721         (JSC::Wasm::CodeBlock::tierUpCount):
1722         (JSC::Wasm::CodeBlock::mode):
1723         * wasm/WasmFormat.h:
1724         (JSC::Wasm::CallableFunction::CallableFunction):
1725         (JSC::Wasm::CallableFunction::offsetOfWasmEntrypointLoadLocation):
1726         * wasm/WasmMachineThreads.cpp: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h.
1727         (JSC::Wasm::wasmThreads):
1728         (JSC::Wasm::startTrackingCurrentThread):
1729         (JSC::Wasm::resetInstructionCacheOnAllThreads):
1730         * wasm/WasmMachineThreads.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.h.
1731         * wasm/WasmModule.cpp:
1732         (JSC::Wasm::makeValidationResult):
1733         (JSC::Wasm::makeValidationCallback):
1734         (JSC::Wasm::Module::validateSync):
1735         (JSC::Wasm::Module::validateAsync):
1736         * wasm/WasmModule.h:
1737         (JSC::Wasm::Module::codeBlockFor):
1738         * wasm/WasmOMGPlan.cpp: Added.
1739         (JSC::Wasm::OMGPlan::OMGPlan):
1740         (JSC::Wasm::OMGPlan::work):
1741         (JSC::Wasm::runOMGPlanForIndex):
1742         * wasm/WasmOMGPlan.h: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h.
1743         * wasm/WasmPlan.cpp:
1744         (JSC::Wasm::Plan::Plan):
1745         (JSC::Wasm::Plan::runCompletionTasks):
1746         (JSC::Wasm::Plan::addCompletionTask):
1747         (JSC::Wasm::Plan::waitForCompletion):
1748         (JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast):
1749         (JSC::Wasm::Plan::fail):
1750         (JSC::Wasm::Plan::stateString): Deleted.
1751         (JSC::Wasm::Plan::moveToState): Deleted.
1752         (JSC::Wasm::Plan::parseAndValidateModule): Deleted.
1753         (JSC::Wasm::Plan::prepare): Deleted.
1754         (JSC::Wasm::Plan::ThreadCountHolder::ThreadCountHolder): Deleted.
1755         (JSC::Wasm::Plan::ThreadCountHolder::~ThreadCountHolder): Deleted.
1756         (JSC::Wasm::Plan::compileFunctions): Deleted.
1757         (JSC::Wasm::Plan::complete): Deleted.
1758         * wasm/WasmPlan.h:
1759         (JSC::Wasm::Plan::exports): Deleted.
1760         (JSC::Wasm::Plan::internalFunctionCount): Deleted.
1761         (JSC::Wasm::Plan::takeModuleInformation): Deleted.
1762         (JSC::Wasm::Plan::takeCallLinkInfos): Deleted.
1763         (JSC::Wasm::Plan::takeWasmToWasmExitStubs): Deleted.
1764         (JSC::Wasm::Plan::hasWork): Deleted.
1765         (JSC::Wasm::Plan::hasBeenPrepared): Deleted.
1766         * wasm/WasmTierUpCount.h: Renamed from Source/JavaScriptCore/wasm/WasmPlanInlines.h.
1767         (JSC::Wasm::TierUpCount::TierUpCount):
1768         (JSC::Wasm::TierUpCount::loopDecrement):
1769         (JSC::Wasm::TierUpCount::functionEntryDecrement):
1770         (JSC::Wasm::TierUpCount::shouldStartTierUp):
1771         (JSC::Wasm::TierUpCount::count):
1772         * wasm/WasmWorklist.cpp:
1773         * wasm/WasmWorklist.h:
1774         (JSC::Wasm::Worklist::nextTicket):
1775         * wasm/js/JSWebAssemblyCodeBlock.cpp:
1776         * wasm/js/JSWebAssemblyCodeBlock.h:
1777         (JSC::JSWebAssemblyCodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace):
1778         (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport):
1779         (JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace): Deleted.
1780         * wasm/js/JSWebAssemblyTable.cpp:
1781         (JSC::JSWebAssemblyTable::setFunction):
1782         * wasm/js/WebAssemblyFunction.cpp:
1783         (JSC::WebAssemblyFunction::create):
1784         (JSC::WebAssemblyFunction::WebAssemblyFunction):
1785         * wasm/js/WebAssemblyFunction.h:
1786         (JSC::WebAssemblyFunction::signatureIndex):
1787         (JSC::WebAssemblyFunction::wasmEntrypointLoadLocation):
1788         (JSC::WebAssemblyFunction::callableFunction):
1789         (JSC::WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation):
1790         (JSC::WebAssemblyFunction::wasmEntrypoint): Deleted.
1791         (JSC::WebAssemblyFunction::offsetOfWasmEntrypoint): Deleted.
1792         * wasm/js/WebAssemblyModuleRecord.cpp:
1793         (JSC::WebAssemblyModuleRecord::link):
1794         (JSC::WebAssemblyModuleRecord::evaluate):
1795         * wasm/js/WebAssemblyPrototype.cpp:
1796         (JSC::webAssemblyValidateFunc):
1797         * wasm/js/WebAssemblyWrapperFunction.cpp:
1798         (JSC::WebAssemblyWrapperFunction::WebAssemblyWrapperFunction):
1799         (JSC::WebAssemblyWrapperFunction::create):
1800         * wasm/js/WebAssemblyWrapperFunction.h:
1801         (JSC::WebAssemblyWrapperFunction::signatureIndex):
1802         (JSC::WebAssemblyWrapperFunction::wasmEntrypointLoadLocation):
1803         (JSC::WebAssemblyWrapperFunction::callableFunction):
1804         (JSC::WebAssemblyWrapperFunction::wasmEntrypoint): Deleted.
1805
1806 2017-04-26  Caitlin Potter  <caitp@igalia.com>
1807
1808         [JSC] fix RETURN_IF_EXCEPTION() placement in ownPropertyKeys()
1809         https://bugs.webkit.org/show_bug.cgi?id=171330
1810
1811         Reviewed by Mark Lam.
1812
1813         Ensure RETURN_IF_EXCEPTION() following invokation of the
1814         filterPropertyIfNeeded() lambda.
1815
1816         * runtime/ObjectConstructor.cpp:
1817         (JSC::ownPropertyKeys):
1818
1819 2017-04-26  Caitlin Potter  <caitp@igalia.com>
1820
1821         [JSC] Object.keys() must discard property names with no PropertyDescriptor
1822         https://bugs.webkit.org/show_bug.cgi?id=171291
1823
1824         Reviewed by Yusuke Suzuki.
1825
1826         Proxy objects can produce an arbitrary list of property names from the
1827         "ownKeys" trap, however the Object.keys() algorithm is required to
1828         discard names which do not have a PropertyDescriptor. This also
1829         applies to other uses of the EnumerableOwnProperties() algorithm
1830         (https://tc39.github.io/ecma262/#sec-enumerableownproperties)
1831
1832         Related to https://bugs.chromium.org/p/v8/issues/detail?id=6290
1833
1834         * runtime/ObjectConstructor.cpp:
1835         (JSC::ownPropertyKeys):
1836
1837 2017-04-25  Andy VanWagoner  <thetalecrafter@gmail.com>
1838
1839         Unhandled enumeration values in IntlDateTimeFormat.cpp
1840         https://bugs.webkit.org/show_bug.cgi?id=171241
1841
1842         Reviewed by JF Bastien.
1843
1844         Added some missing cases of the UDateFormatField to partTypeString,
1845         and made them conditional to the ICU version that added them.
1846         This should remove the warnings that appear on platform builds using the
1847         newer system ICU headers.
1848
1849         * runtime/IntlDateTimeFormat.cpp:
1850         (JSC::IntlDateTimeFormat::partTypeString):
1851
1852 2017-04-25  Commit Queue  <commit-queue@webkit.org>
1853
1854         Unreviewed, rolling out r215476.
1855         https://bugs.webkit.org/show_bug.cgi?id=171304
1856
1857         "It broke JSBench" (Requested by saamyjoon on #webkit).
1858
1859         Reverted changeset:
1860
1861         "[ES6]. Implement Annex B.3.3 function hoisting rules for
1862         eval"
1863         https://bugs.webkit.org/show_bug.cgi?id=163208
1864         http://trac.webkit.org/changeset/215476
1865
1866 2017-04-25  Saam Barati  <sbarati@apple.com>
1867
1868         JSArray::isArrayPrototypeIteratorProtocolFastAndNonObservable is wrong because it does not do the necessary checks on the base object
1869         https://bugs.webkit.org/show_bug.cgi?id=171150
1870         <rdar://problem/31771880>
1871
1872         Reviewed by Sam Weinig.
1873
1874         This patch fixes a huge oversight from the patch that introduced
1875         op_spread/Spread. The original patch did not account for the
1876         base object having Symbol.iterator or getters that could
1877         change the iterator protocol. This patch fixes the oversight both
1878         in the C code, as well as the DFG/FTL backends. We only perform
1879         the memcpy version of spread if we've proven that it's guaranteed
1880         to be side-effect free (no indexed getters), and if the iterator
1881         protocol is guaranteed to be the original protocol. To do this, we
1882         must prove that:
1883         1. The protocol on Array.prototype hasn't changed (this is the same as the
1884         introductory patch for op_spread).
1885         2. The base object's __proto__ is Array.prototype
1886         3. The base object does not have indexed getters
1887         4. The base object does not have Symbol.iterator property.
1888
1889         * dfg/DFGGraph.cpp:
1890         (JSC::DFG::Graph::canDoFastSpread):
1891         * dfg/DFGGraph.h:
1892         * dfg/DFGSpeculativeJIT.cpp:
1893         (JSC::DFG::SpeculativeJIT::compileSpread):
1894         * ftl/FTLLowerDFGToB3.cpp:
1895         (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
1896         * runtime/JSArray.cpp:
1897         (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
1898         * runtime/JSArray.h:
1899         * runtime/JSArrayInlines.h:
1900         (JSC::JSArray::isIteratorProtocolFastAndNonObservable): Deleted.
1901         * runtime/JSGlobalObject.h:
1902         * runtime/JSGlobalObjectInlines.h:
1903         (JSC::JSGlobalObject::isArrayPrototypeIteratorProtocolFastAndNonObservable):
1904         (JSC::JSGlobalObject::isArrayIteratorProtocolFastAndNonObservable): Deleted.
1905
1906 2017-04-25  Mark Lam  <mark.lam@apple.com>
1907
1908         Array.prototype.slice() should ensure that end >= begin.
1909         https://bugs.webkit.org/show_bug.cgi?id=170989
1910         <rdar://problem/31705652>
1911
1912         Reviewed by Saam Barati.
1913
1914         * runtime/ArrayPrototype.cpp:
1915         (JSC::arrayProtoFuncSlice):
1916
1917 2017-04-25  Don Olmstead  <don.olmstead@am.sony.com>
1918
1919         [Win] Use Clang's __has_declspec_attribute for export macros
1920         https://bugs.webkit.org/show_bug.cgi?id=171240
1921
1922         Reviewed by Alex Christensen.
1923
1924         * runtime/JSExportMacros.h:
1925
1926 2017-04-25  Saam Barati  <sbarati@apple.com>
1927
1928         Unreviewed. Attempt armv7k build fix after r215720
1929
1930         I think we're just missing an include for the definition of ExecState::r().
1931
1932         * runtime/JSFixedArray.cpp:
1933
1934 2017-04-25  Daniel Bates  <dabates@apple.com>
1935
1936         [Cocoa][Win] Enable of X-Content-Type-Options: nosniff header
1937         https://bugs.webkit.org/show_bug.cgi?id=136452
1938         <rdar://problem/23412620>
1939
1940         Reviewed by Brent Fulgham.
1941
1942         Enable X-Content-Type-Options: nosniff on Mac, iOS and Windows platforms.
1943
1944         * Configurations/FeatureDefines.xcconfig:
1945
1946 2017-04-25  Mark Lam  <mark.lam@apple.com>
1947
1948         Local CSE wrongly CSEs array accesses with different result types.
1949         https://bugs.webkit.org/show_bug.cgi?id=170990
1950         <rdar://problem/31705945>
1951
1952         Reviewed by Saam Barati.
1953
1954         The fix is to use different LocationKind enums for the different type of array
1955         result types.  This makes the HeapLocation values different based on the result
1956         types, and allows CSE to discern between them.
1957
1958         * dfg/DFGCSEPhase.cpp:
1959         * dfg/DFGClobberize.h:
1960         (JSC::DFG::clobberize):
1961         * dfg/DFGHeapLocation.cpp:
1962         (WTF::printInternal):
1963         * dfg/DFGHeapLocation.h:
1964         (JSC::DFG::indexedPropertyLocForResultType):
1965
1966 2017-04-25  Mark Lam  <mark.lam@apple.com>
1967
1968         Make DFG SpeculatedType dumps easier to read.
1969         https://bugs.webkit.org/show_bug.cgi?id=171280
1970
1971         Reviewed by Saam Barati.
1972
1973         Adding a pretty printer to insert |s between each type string and changing the
1974         dumped strings to match the SpeculatedType names case-wise.
1975
1976         * bytecode/SpeculatedType.cpp:
1977         (JSC::PrettyPrinter::PrettyPrinter):
1978         (JSC::PrettyPrinter::print):
1979         (JSC::dumpSpeculation):
1980         * bytecode/SpeculatedType.h:
1981
1982 2017-04-25  JF Bastien  <jfbastien@apple.com>
1983
1984         lowerStackArgs: check Arg::addr.isValidForm when falling back to SP offsets
1985         https://bugs.webkit.org/show_bug.cgi?id=171278
1986
1987         Reviewed by Filip Pizlo.
1988
1989         lowerStackArgs checked that the FP offsets it tries to generate
1990         are valid form, but didn't check that the fallback was valid
1991         form. This lead to stackAddr's assertion being dead, and the
1992         MaroAssembler asserting way later on move / add when handed a huge
1993         immediate.
1994
1995         * b3/air/AirArg.cpp:
1996         (JSC::B3::Air::Arg::stackAddrImpl):
1997
1998 2017-04-25  Zan Dobersek  <zdobersek@igalia.com>
1999
2000         [aarch64] moveConditionally32(), moveConditionallyTest32() should move from/to 64-bit registers
2001         https://bugs.webkit.org/show_bug.cgi?id=170891
2002
2003         Reviewed by Saam Barati.
2004
2005         moveConditionally32() and moveConditionallyTest32() operations in
2006         MacroAssemblerARM64 properly perform comparisons and tests on 32-bit
2007         values, but end up performing the moves from and to 32-bit registers.
2008
2009         Move operations should instead be done on 64-bit registers, just like
2010         on the X86_64 platform. This is achieved by specifying 64 as the data
2011         size for the csel instructions.
2012
2013         * assembler/MacroAssemblerARM64.h:
2014         (JSC::MacroAssemblerARM64::moveConditionally32):
2015         (JSC::MacroAssemblerARM64::moveConditionallyTest32):
2016
2017 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
2018
2019         test262: test262/test/language/expressions/object/method-definition/early-errors-object-method-duplicate-parameters.js
2020         https://bugs.webkit.org/show_bug.cgi?id=171190
2021
2022         Reviewed by Saam Barati.
2023
2024         * bytecompiler/BytecodeGenerator.cpp:
2025         (JSC::BytecodeGenerator::BytecodeGenerator):
2026         (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
2027         (JSC::BytecodeGenerator::emitNewFunction):
2028         * bytecompiler/NodesCodegen.cpp:
2029         (JSC::FunctionNode::emitBytecode):
2030         (JSC::Scope::setSourceParseMode):
2031         * parser/ParserModes.h:
2032         (JSC::isFunctionParseMode):
2033         (JSC::isMethodParseMode):
2034         (JSC::isGeneratorOrAsyncFunctionWrapperParseMode):
2035         (JSC::isGeneratorParseMode):
2036         (JSC::isGeneratorWrapperParseMode):
2037         * runtime/FunctionExecutable.h:
2038         * runtime/JSFunction.cpp:
2039         (JSC::JSFunction::getOwnPropertySlot):
2040         Add a new GeneratorWrapperMethodMode parse mode. The other function types
2041         (async, arrow) already have a FunctionMode and a MethodMode. Give
2042         generators one as well. This lets isMethodParseMode actually be accurate.
2043
2044         * parser/Parser.cpp:
2045         (JSC::Parser<LexerType>::parseInner):
2046         (JSC::Parser<LexerType>::isArrowFunctionParameters):
2047         (JSC::Parser<LexerType>::parseFormalParameters):
2048         (JSC::stringForFunctionMode):
2049         (JSC::Parser<LexerType>::parseFunctionParameters):
2050         (JSC::Parser<LexerType>::parseFunctionInfo):
2051         (JSC::Parser<LexerType>::parseClass):
2052         (JSC::Parser<LexerType>::parsePropertyMethod):
2053         * parser/Parser.h:
2054         Add a duplicate parameter failure if there are duplicate parameters
2055         in method syntax.
2056
2057 2017-04-24  Andy VanWagoner  <thetalecrafter@gmail.com>
2058
2059         Clean up ICU headers
2060         https://bugs.webkit.org/show_bug.cgi?id=170997
2061
2062         Reviewed by JF Bastien.
2063
2064         Update all icu headers to 55.1
2065
2066         * icu/LICENSE: Update copyright
2067         * icu/README: Explain ICU headers for OS X better
2068         * icu/unicode/localpointer.h:
2069         (LocalPointer::LocalPointer):
2070         (LocalPointer::adoptInsteadAndCheckErrorCode):
2071         * icu/unicode/platform.h:
2072         * icu/unicode/putil.h:
2073         * icu/unicode/ucal.h:
2074         * icu/unicode/uchar.h:
2075         * icu/unicode/ucnv.h:
2076         * icu/unicode/ucol.h:
2077         * icu/unicode/uconfig.h:
2078         * icu/unicode/ucurr.h:
2079         * icu/unicode/udatpg.h:
2080         * icu/unicode/udisplaycontext.h:
2081         * icu/unicode/uformattable.h:
2082         * icu/unicode/uloc.h:
2083         * icu/unicode/umachine.h:
2084         * icu/unicode/unum.h:
2085         * icu/unicode/unumsys.h:
2086         * icu/unicode/urename.h:
2087         * icu/unicode/uscript.h:
2088         * icu/unicode/uset.h:
2089         * icu/unicode/ustring.h:
2090         * icu/unicode/utf8.h:
2091         * icu/unicode/utypes.h:
2092
2093 2017-04-24  Yusuke Suzuki  <utatane.tea@gmail.com>
2094
2095         [JSC] Use JSFixedArray directly when using call_varargs
2096         https://bugs.webkit.org/show_bug.cgi?id=171057
2097
2098         Reviewed by Saam Barati.
2099
2100         Previously we always emit new_array_with_spread when calling call(...args).
2101         But this array is unnecessary if varargs operation can handle Spread directly.
2102
2103         This patch implements a peep-hole optimization in the bytecode compiler layer
2104         to omit new_array_with_spread. This is very simple and effective because this
2105         peep-hole optimization is quite common when using (...args) style calls and
2106         this optimization works all the tiers. While we can implement the phase to
2107         omit this NewArrayWithSpread in argument elimination phase, it only works
2108         for FTL. While such an optimization can work with complex data flow, this
2109         peep-hole optimization can optimize a common case easily.
2110
2111         For now, Spread and PhantomSpread can be directly drained by CallVarargs
2112         and LoadVarargs related operations. We modify DFG and FTL to handle this correctly.
2113
2114         This shows six-speed improvement.
2115
2116             spread.es6                 89.4300+-2.0236     ^     69.6015+-1.7278        ^ definitely 1.2849x faster
2117             spread-generator.es6      344.7879+-5.9147     ^    331.2712+-6.8610        ^ definitely 1.0408x faster
2118
2119         * bytecompiler/BytecodeGenerator.cpp:
2120         (JSC::BytecodeGenerator::emitCall):
2121         (JSC::BytecodeGenerator::emitConstruct):
2122         * dfg/DFGArgumentsEliminationPhase.cpp:
2123         * dfg/DFGPreciseLocalClobberize.h:
2124         (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
2125         * ftl/FTLLowerDFGToB3.cpp:
2126         (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
2127         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
2128         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
2129         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
2130         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread):
2131         * interpreter/Interpreter.cpp:
2132         (JSC::sizeOfVarargs):
2133         (JSC::loadVarargs):
2134         * parser/Nodes.h:
2135         (JSC::ArrayNode::elements):
2136         * runtime/JSFixedArray.cpp:
2137         (JSC::JSFixedArray::copyToArguments):
2138         * runtime/JSFixedArray.h:
2139
2140 2017-04-24  Yusuke Suzuki  <utatane.tea@gmail.com>
2141
2142         [WTF] Move JSC tools/StackTrace to WTF and unify stack trace dump code
2143         https://bugs.webkit.org/show_bug.cgi?id=171199
2144
2145         Reviewed by Mark Lam.
2146
2147         This patch adds a utility method to produce demangled names with dladdr.
2148         It fixes several memory leaks because the result of abi::__cxa_demangle()
2149         needs to be `free`-ed.
2150
2151         * CMakeLists.txt:
2152         * JavaScriptCore.xcodeproj/project.pbxproj:
2153         * inspector/JSGlobalObjectInspectorController.cpp:
2154         (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
2155         * runtime/SamplingProfiler.cpp:
2156         (JSC::SamplingProfiler::StackFrame::displayName):
2157         * tools/CellProfile.h:
2158         * tools/CodeProfile.cpp:
2159         (JSC::CodeProfile::report):
2160         (JSC::symbolName): Deleted.
2161
2162 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
2163
2164         Web Inspector: ObjC RWIProtocol codegen should better handle optional members
2165         https://bugs.webkit.org/show_bug.cgi?id=171251
2166         <rdar://problem/31697002>
2167
2168         Reviewed by Brian Burg.
2169
2170         * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
2171         (ObjCProtocolTypesImplementationGenerator._generate_getter_for_member):
2172         * inspector/scripts/codegen/objc_generator.py:
2173         (ObjCGenerator.protocol_to_objc_expression_for_member):
2174         (ObjCGenerator.protocol_to_objc_code_block_for_object_member):
2175         Always be safe and nil check object property accesses, optional or not.
2176
2177         * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
2178         * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
2179         Rebaselined inspector generator tests.
2180
2181 2017-04-24  Saam Barati  <sbarati@apple.com>
2182
2183         ASSERTION FAILED: m_table seen with workers/wasm-hashset LayoutTests
2184         https://bugs.webkit.org/show_bug.cgi?id=171119
2185         <rdar://problem/31760635>
2186
2187         Reviewed by Keith Miller.
2188
2189         The HashSet of timer set notification callbacks can be accessed
2190         and augmented simultaneously from different threads. e.g, the worker
2191         thread can augment it while the wasm compilation thread will
2192         access it. Therefore, accesses must be guarded by a lock.
2193
2194         * runtime/JSRunLoopTimer.cpp:
2195         (JSC::JSRunLoopTimer::scheduleTimer):
2196         (JSC::JSRunLoopTimer::addTimerSetNotification):
2197         (JSC::JSRunLoopTimer::removeTimerSetNotification):
2198         * runtime/JSRunLoopTimer.h:
2199
2200 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
2201
2202         test262: test262/test/language/computed-property-names/class/static/getter-prototype.js
2203         https://bugs.webkit.org/show_bug.cgi?id=170897
2204
2205         Reviewed by Saam Barati.
2206
2207         * parser/ASTBuilder.h:
2208         (JSC::ASTBuilder::createArguments):
2209         (JSC::ASTBuilder::createArgumentsList):
2210         Reorder so all the createProperty methods are grouped together.
2211
2212         * parser/Parser.h:
2213         * parser/Parser.cpp:
2214         (JSC::Parser<LexerType>::parseClass):
2215         (JSC::Parser<LexerType>::parseProperty):
2216         (JSC::Parser<LexerType>::parseGetterSetter):
2217         Refine the conditions for syntax errors for getter/setter
2218         properties names. "prototype" is not allowed as a static
2219         and "constructor" is not all when non-static.
2220
2221         * runtime/JSObject.cpp:
2222         (JSC::JSObject::putGetter):
2223         (JSC::JSObject::putSetter):
2224         Throw exceptions. These methods are only used by this path
2225         via op_put_getter_by_val / op_put_setter_by_val.
2226
2227 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
2228
2229         test262: test262/test/language/statements/for-of/dstr-array-elem-init-fn-name-arrow.js
2230         https://bugs.webkit.org/show_bug.cgi?id=171160
2231
2232         Reviewed by JF Bastien.
2233
2234         * parser/ASTBuilder.h:
2235         (JSC::ASTBuilder::tryInferNameInPattern):
2236         (JSC::ASTBuilder::tryInferNameInPatternWithIdentifier):
2237         We supported getting the name from a BindingNode.
2238         We extend this to support getting the name from a
2239         ResolveNode inside of an AssignmentElementNode.
2240
2241         * parser/Nodes.h:
2242         (JSC::DestructuringPatternNode::isAssignmentElementNode):
2243         (JSC::AssignmentElementNode::isAssignmentElementNode):
2244         Make it possible to identify an assignment element node.
2245
2246 2017-04-24  Alex Christensen  <achristensen@webkit.org>
2247
2248         Reduce copies and allocations in SharedBuffer::append
2249         https://bugs.webkit.org/show_bug.cgi?id=170956
2250
2251         Reviewed by Andreas Kling.
2252
2253         * runtime/ArrayBuffer.h:
2254
2255 2017-04-24  Carlos Garcia Campos  <cgarcia@igalia.com>
2256
2257         [GTK] Switch to use ENABLE_REMOTE_INSPECTOR instead of ENABLE_INSPECTOR_SERVER for the remote inspector
2258         https://bugs.webkit.org/show_bug.cgi?id=166680
2259
2260         Reviewed by Michael Catanzaro.
2261
2262         Add GTK+ port implementation of RemoteInspector.
2263
2264         * PlatformGTK.cmake:
2265         * inspector/remote/RemoteConnectionToTarget.h:
2266         * inspector/remote/RemoteInspector.h:
2267         * inspector/remote/glib/RemoteConnectionToTargetGlib.cpp: Added.
2268         (Inspector::RemoteConnectionToTarget::RemoteConnectionToTarget):
2269         (Inspector::RemoteConnectionToTarget::~RemoteConnectionToTarget):
2270         (Inspector::RemoteConnectionToTarget::setup):
2271         (Inspector::RemoteConnectionToTarget::sendMessageToTarget):
2272         (Inspector::RemoteConnectionToTarget::close):
2273         (Inspector::RemoteConnectionToTarget::targetClosed):
2274         (Inspector::RemoteConnectionToTarget::targetIdentifier):
2275         (Inspector::RemoteConnectionToTarget::sendMessageToFrontend):
2276         * inspector/remote/glib/RemoteInspectorGlib.cpp: Added.
2277         (Inspector::RemoteInspector::singleton):
2278         (Inspector::RemoteInspector::RemoteInspector):
2279         (Inspector::RemoteInspector::start):
2280         (Inspector::RemoteInspector::stopInternal):
2281         (Inspector::RemoteInspector::setupConnection):
2282         (Inspector::dbusConnectionCallAsyncReadyCallback):
2283         (Inspector::RemoteInspector::listingForInspectionTarget):
2284         (Inspector::RemoteInspector::listingForAutomationTarget):
2285         (Inspector::RemoteInspector::pushListingsNow):
2286         (Inspector::RemoteInspector::pushListingsSoon):
2287         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
2288         (Inspector::RemoteInspector::sendAutomaticInspectionCandidateMessage):
2289         (Inspector::RemoteInspector::sendMessageToRemote):
2290         (Inspector::RemoteInspector::receivedGetTargetListMessage):
2291         (Inspector::RemoteInspector::receivedSetupMessage):
2292         (Inspector::RemoteInspector::receivedDataMessage):
2293         (Inspector::RemoteInspector::receivedCloseMessage):
2294         (Inspector::RemoteInspector::setup):
2295         (Inspector::RemoteInspector::sendMessageToTarget):
2296         (Inspector::RemoteInspector::requestAutomationSession):
2297         * inspector/remote/glib/RemoteInspectorServer.cpp: Added.
2298         (Inspector::generateConnectionID):
2299         (Inspector::RemoteInspectorServer::singleton):
2300         (Inspector::RemoteInspectorServer::~RemoteInspectorServer):
2301         (Inspector::RemoteInspectorServer::interfaceInfo):
2302         (Inspector::RemoteInspectorServer::start):
2303         (Inspector::RemoteInspectorServer::newConnectionCallback):
2304         (Inspector::RemoteInspectorServer::connectionClosedCallback):
2305         (Inspector::RemoteInspectorServer::newConnection):
2306         (Inspector::dbusConnectionCallAsyncReadyCallback):
2307         (Inspector::RemoteInspectorServer::setTargetList):
2308         (Inspector::RemoteInspectorServer::clientConnectionClosedCallback):
2309         (Inspector::RemoteInspectorServer::getTargetList):
2310         (Inspector::RemoteInspectorServer::setup):
2311         (Inspector::RemoteInspectorServer::close):
2312         (Inspector::RemoteInspectorServer::clientConnectionClosed):
2313         (Inspector::RemoteInspectorServer::connectionClosed):
2314         (Inspector::RemoteInspectorServer::sendMessageToBackend):
2315         (Inspector::RemoteInspectorServer::sendMessageToFrontend):
2316         (Inspector::RemoteInspectorServer::startAutomationSession):
2317         * inspector/remote/glib/RemoteInspectorServer.h: Added.
2318         (Inspector::RemoteInspectorServer::isRunning):
2319
2320 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
2321
2322         test262: test262/test/language/expressions/generators/yield-as-label.js
2323         https://bugs.webkit.org/show_bug.cgi?id=170979
2324
2325         Reviewed by Saam Barati.
2326
2327         * parser/Parser.cpp:
2328         (JSC::Parser<LexerType>::parseVariableDeclarationList):
2329         (JSC::Parser<LexerType>::parseDestructuringPattern):
2330         (JSC::Parser<LexerType>::parseFormalParameters):
2331         Converge on "Cannot" instead of "Can't" in error messages.
2332
2333         (JSC::Parser<LexerType>::parseFunctionInfo):
2334         Disallow "yield" as the generator function name in function expressions.
2335         This refers to the difference between Declaration and Expression, where
2336         only GeneratorExpression explicitly has [+Yield] disallowing yield for
2337         the generator name:
2338
2339             GeneratorDeclaration[Yield, Await, Default]:
2340                 function * BindingIdentifier[?Yield, ?Await] ...
2341
2342             GeneratorExpression:
2343                 function * BindingIdentifier[+Yield, ~Await]opt ...
2344
2345         (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
2346         Disallow "yield" as a label name in strict mode or inside a generator.
2347
2348         (JSC::Parser<LexerType>::parseProperty):
2349         Disallow "yield" or any keyword in object literal shorthands.
2350
2351         * parser/Parser.h:
2352         (JSC::Parser::getToken):
2353         (JSC::Parser::isDisallowedIdentifierLet):
2354         (JSC::Parser::isDisallowedIdentifierYield):
2355         (JSC::Parser::disallowedIdentifierLetReason):
2356         (JSC::Parser::disallowedIdentifierYieldReason):
2357         Follow pattern for improved error messages based on context.
2358
2359 2017-04-23  Commit Queue  <commit-queue@webkit.org>
2360
2361         Unreviewed, rolling out r215674.
2362         https://bugs.webkit.org/show_bug.cgi?id=171212
2363
2364         Possible unintended commit. This patch was on the wrong bug.
2365         (Requested by JoePeck on #webkit).
2366
2367         Reverted changeset:
2368
2369         "test262: test262/test/language/expressions/generators/yield-
2370         as-label.js"
2371         https://bugs.webkit.org/show_bug.cgi?id=170979
2372         http://trac.webkit.org/changeset/215674
2373
2374 2017-04-23  Joseph Pecoraro  <pecoraro@apple.com>
2375
2376         test262: test262/test/built-ins/Number/prototype/toPrecision/nan.js
2377         https://bugs.webkit.org/show_bug.cgi?id=171197
2378
2379         Reviewed by Saam Barati.
2380
2381         * runtime/NumberPrototype.cpp:
2382         (JSC::numberProtoFuncToExponential):
2383         (JSC::numberProtoFuncToFixed):
2384         (JSC::numberProtoFuncToPrecision):
2385         Refine the order of operations to match the spec.
2386
2387 2017-04-23  Joseph Pecoraro  <pecoraro@apple.com>
2388
2389         test262: test262/test/language/expressions/generators/yield-as-label.js
2390         https://bugs.webkit.org/show_bug.cgi?id=170979
2391
2392         Reviewed by Saam Barati.
2393
2394         * parser/Parser.cpp:
2395         (JSC::Parser<LexerType>::parseVariableDeclarationList):
2396         (JSC::Parser<LexerType>::parseDestructuringPattern):
2397         (JSC::Parser<LexerType>::parseFormalParameters):
2398         Converge on "Cannot" instead of "Can't" in error messages.
2399
2400         (JSC::Parser<LexerType>::parseFunctionInfo):
2401         Disallow "yield" as the generator function name in function expressions.
2402         This refers to the difference between Declaration and Expression, where
2403         only GeneratorExpression explicitly has [+Yield] disallowing yield for
2404         the generator name:
2405
2406             GeneratorDeclaration[Yield, Await, Default]:
2407                 function * BindingIdentifier[?Yield, ?Await] ...
2408
2409             GeneratorExpression:
2410                 function * BindingIdentifier[+Yield, ~Await]opt ...
2411
2412         (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
2413         Disallow "yield" as a label name in strict mode or inside a generator.
2414
2415         (JSC::Parser<LexerType>::parseProperty):
2416         Disallow "yield" or any keyword in object literal shorthands.
2417
2418         * parser/Parser.h:
2419         (JSC::Parser::getToken):
2420         (JSC::Parser::isDisallowedIdentifierLet):
2421         (JSC::Parser::isDisallowedIdentifierYield):
2422         (JSC::Parser::disallowedIdentifierLetReason):
2423         (JSC::Parser::disallowedIdentifierYieldReason):
2424         Follow pattern for improved error messages based on context.
2425
2426 2017-04-23  Joseph Pecoraro  <pecoraro@apple.com>
2427
2428         test262: test262/test/built-ins/Number/parseFloat.js
2429         https://bugs.webkit.org/show_bug.cgi?id=171193
2430
2431         Reviewed by Yusuke Suzuki.
2432
2433         * runtime/CommonIdentifiers.h:
2434         * runtime/JSGlobalObject.cpp:
2435         (JSC::JSGlobalObject::init):
2436         (JSC::JSGlobalObject::visitChildren):
2437         * runtime/JSGlobalObject.h:
2438         (JSC::JSGlobalObject::parseFloatFunction):
2439         Expose parseFloat on the global object to be shared with Number constructor.
2440
2441         * runtime/NumberConstructor.cpp:
2442         (JSC::NumberConstructor::finishCreation):
2443         parseFloat uses the same value as the global parseFloat.
2444
2445 2017-04-22  Yusuke Suzuki  <utatane.tea@gmail.com>
2446
2447         [JSC] Use DoublyLinkedList for MachineThread
2448         https://bugs.webkit.org/show_bug.cgi?id=171171
2449
2450         Reviewed by Mark Lam.
2451
2452         MachineThread can use WTF::DoublyLinkedList to simplify
2453         its implementation. We should not use Vector<> etc. since
2454         we do not want to call allocations during suspending and
2455         resuming threads.
2456
2457         * heap/MachineStackMarker.cpp:
2458         (JSC::MachineThreads::MachineThreads):
2459         (JSC::MachineThreads::~MachineThreads):
2460         (JSC::MachineThreads::addCurrentThread):
2461         (JSC::MachineThreads::removeThreadIfFound):
2462         (JSC::MachineThreads::MachineThread::MachineThread):
2463         (JSC::MachineThreads::tryCopyOtherThreadStacks):
2464         * heap/MachineStackMarker.h:
2465         (JSC::MachineThreads::threadsListHead):
2466         * runtime/SamplingProfiler.cpp:
2467         (JSC::FrameWalker::isValidFramePointer):
2468         * runtime/VMTraps.cpp:
2469         (JSC::findActiveVMAndStackBounds):
2470
2471 2017-04-22  JF Bastien  <jfbastien@apple.com>
2472
2473         WebAssembly: Module.exports, Module.imports, Module.customSections are wrong
2474         https://bugs.webkit.org/show_bug.cgi?id=171078
2475
2476         Reviewed by Saam Barati.
2477
2478         They're static properties of Module, not instance properties of a module.
2479         https://github.com/WebAssembly/design/blob/master/JS.md#webassemblymoduleexports
2480
2481         * wasm/js/WebAssemblyModuleConstructor.cpp:
2482         (JSC::webAssemblyModuleCustomSections):
2483         (JSC::webAssemblyModuleImports):
2484         (JSC::webAssemblyModuleExports):
2485         * wasm/js/WebAssemblyModulePrototype.cpp:
2486         (JSC::webAssemblyModuleProtoCustomSections): Deleted.
2487         (JSC::webAssemblyModuleProtoImports): Deleted.
2488         (JSC::webAssemblyModuleProtoExports): Deleted.
2489
2490 2017-04-21  Saam Barati  <sbarati@apple.com>
2491
2492         SharedArrayBuffer-opt.js fails with Briggs
2493         https://bugs.webkit.org/show_bug.cgi?id=170948
2494         <rdar://problem/31740568>
2495
2496         Reviewed by Michael Saboff.
2497
2498         The bug was not actually with Briggs, but instead was with
2499         our X86-64 MacroAssembler. Michael fixed the bug here:
2500         https://trac.webkit.org/changeset/215618/webkit
2501         
2502         The issue was we weren't adding the REX byte for AtomicXchg8,
2503         leading to the incorrect encoding for the result register depending
2504         on which register it was. If you look at this code, you'll see the issue:
2505
2506           Int32 @38 = AtomicXchg(@59, @64, width = 8, range = 0, fenceRange = 0, ControlDependent|Fence|Writes:0|Reads:0, DFG:@49)
2507               AtomicXchg8 %rsi, (%rax,%rdx), @38
2508                   0x2dcb5bc0015e: lock xchg %dh, (%rax,%rdx)
2509           Int32 @66 = Const32(255, DFG:@49)
2510           Int32 @67 = BitAnd(@38, $255(@66), DFG:@49)
2511               ZeroExtend8To32 %rsi, %rax, @67
2512                   0x2dcb5bc00162: movzx %sil, %eax
2513
2514         Air thought the result was in the lower 8 bits of %rsi,
2515         however, the code we emitted stored it in the [8-15] bits
2516         of %rdx. Since this issue is fixed, I'm turning Briggs back
2517         on.
2518
2519         * b3/air/AirAllocateRegistersByGraphColoring.h:
2520         (JSC::B3::Air::useIRC):
2521
2522 2017-04-20  Mark Lam  <mark.lam@apple.com>
2523
2524         Refactor MASM probe to allow printing of custom types.
2525         https://bugs.webkit.org/show_bug.cgi?id=171101
2526
2527         Reviewed by JF Bastien.
2528
2529         For example, this allows us to add MASM printing of CodeBlock* and Air::Args.
2530
2531         In general, MASM print can be used like dataLog, except that it generates JITted
2532         code for doing the dataLogging later when the JITted code runs.  MASM print can
2533         print any value type that a specialized Printer template or a setPrinter()
2534         function implemented for that type.
2535
2536         * CMakeLists.txt:
2537         * JavaScriptCore.xcodeproj/project.pbxproj:
2538         * assembler/MacroAssembler.h:
2539
2540         * assembler/MacroAssemblerPrinter.cpp:
2541         (JSC::Printer::printAllRegisters):
2542         (JSC::Printer::printPCRegister):
2543         (JSC::Printer::printRegisterID):
2544         (JSC::Printer::printFPRegisterID):
2545         (JSC::Printer::printAddress):
2546         (JSC::Printer::printMemory):
2547         (JSC::Printer::printCallback):
2548         (JSC::printIndent): Deleted.
2549         (JSC::printCPU): Deleted.
2550         (JSC::printCPURegisters): Deleted.
2551         (JSC::printPC): Deleted.
2552         (JSC::printRegister): Deleted.
2553         (JSC::printMemory): Deleted.
2554         (JSC::MacroAssemblerPrinter::printCallback): Deleted.
2555         * assembler/MacroAssemblerPrinter.h:
2556         (JSC::AllRegisters::AllRegisters):
2557         (JSC::Printer::Printer<AllRegisters>::Printer):
2558         (JSC::Printer::Printer<PCRegister>::Printer):
2559         (JSC::Printer::Printer<MacroAssembler::RegisterID>::Printer):
2560         (JSC::Printer::Printer<MacroAssembler::FPRegisterID>::Printer):
2561         (JSC::Printer::Printer<MacroAssembler::Address>::Printer):
2562         (JSC::Printer::Printer<Memory>::Printer):
2563         (JSC::Printer::Printer<MemWord<IntType>>::Printer):
2564         (JSC::MacroAssembler::print):
2565         (JSC::MacroAssemblerPrinter::print): Deleted.
2566         (JSC::MacroAssemblerPrinter::PrintArg::PrintArg): Deleted.
2567         (JSC::MacroAssemblerPrinter::appendPrintArg): Deleted.
2568         - Refactored to move the underlying PrintRecord (and associated data structures)
2569           out to Printer.cpp/h.
2570         - MacroAssemblerPrinter.cpp/h now only add custom Printers for MASM types like
2571           RegisterID and Memory.  It also defines the implementation of
2572           MacroAssembler::print().
2573
2574           As before, JIT code that wishes to use MacroAssembler::print() needs to
2575           #include "MacroAssemblerPrinter.h".
2576
2577         - Also added the ability to specify an optional indentation (in number of chars)
2578           when MASM printing AllRegisters.  This is useful because AllRegisters prints
2579           a block of data unlike other printers which print inline.
2580
2581         * assembler/Printer.cpp: Added.
2582         (JSC::Printer::printConstCharString):
2583         (JSC::Printer::printIntptr):
2584         (JSC::Printer::printUintptr):
2585         (JSC::Printer::printPointer):
2586         (JSC::Printer::setPrinter):
2587         * assembler/Printer.h: Added.
2588         (JSC::Printer::Context::Context):
2589         (JSC::Printer::PrintRecord::PrintRecord):
2590         (JSC::Printer::appendPrinter):
2591         (JSC::Printer::makePrintRecordList):
2592         (JSC::Printer::Printer<RawPointer>::Printer):
2593         (JSC::Printer::setPrinter):
2594         (JSC::Printer::Printer::Printer):
2595         - Data structures for creating a list of PrintRecords.  Classes which wish to
2596           add custom support for MASM printing can #include "Printer.h" and implement
2597           either:
2598           1. a specialized Printer template, or
2599           2. a setPrinter() function.
2600
2601           See Printer<Reg> and Printer<B3::Air::Tmp> in AirPrintSpecial.h for examples of
2602           (1).  See CodeBlock's setPrinter() for an example of (2).
2603
2604         * b3/B3LowerToAir.cpp:
2605         (JSC::B3::Air::LowerToAir::print):
2606         * b3/air/AirPrintSpecial.cpp: Added.
2607         (JSC::B3::Air::PrintSpecial::PrintSpecial):
2608         (JSC::B3::Air::PrintSpecial::~PrintSpecial):
2609         (JSC::B3::Air::PrintSpecial::forEachArg):
2610         (JSC::B3::Air::PrintSpecial::isValid):
2611         (JSC::B3::Air::PrintSpecial::admitsStack):
2612         (JSC::B3::Air::PrintSpecial::reportUsedRegisters):
2613         (JSC::B3::Air::PrintSpecial::generate):
2614         (JSC::B3::Air::PrintSpecial::extraEarlyClobberedRegs):
2615         (JSC::B3::Air::PrintSpecial::extraClobberedRegs):
2616         (JSC::B3::Air::PrintSpecial::dumpImpl):
2617         (JSC::B3::Air::PrintSpecial::deepDumpImpl):
2618         (JSC::Printer::printAirArg):
2619         * b3/air/AirPrintSpecial.h: Added.
2620         (JSC::Printer::appendAirArg):
2621         (JSC::Printer::appendAirArgs):
2622         (JSC::Printer::Printer<B3::Air::Tmp>::Printer):
2623         (JSC::Printer::Printer<Reg>::Printer):
2624         - Add the print() operation for use in LowerToAir.  print() will emit a
2625           PrintSpecial that will ultimately emit a MASM print to print what we want.
2626         - LowerToAir's print() adds the ability to print Air::Args.
2627         - Unlike in the baseline JIT and the DFG, LowerToAir's print() can perturb the
2628           usage of registers.  This is because PrintSpecial is a patch point, and it
2629           prevents certain optimizations.  If not used carefully, an attempt to print()
2630           an Arg by taking a Tmp, can force the B3 Value into a Tmp earlier than it would
2631           otherwise do so.  So, use LowerToAir's print() with care.
2632
2633         * bytecode/CodeBlock.cpp:
2634         (JSC::setPrinter):
2635         - Now we can MASM print CodeBlock*.
2636         (WTF::printInternal):
2637         - Now we can dataLog CodeBlock* (including null CodeBlock pointers).
2638
2639         * bytecode/CodeBlock.h:
2640
2641         * runtime/VM.cpp:
2642         (JSC::VM::throwException):
2643         - Use the new ability to dataLog CodeBlock*.  No need to do an explicit null
2644           check before printing anymore.
2645
2646 2017-04-21  Keith Miller  <keith_miller@apple.com>
2647
2648         Unreviewed, rolling out r215634.
2649
2650         underlying build issues should have been fixed
2651
2652         Reverted changeset:
2653
2654         "Unreviewed, rolling out r215620 and r215623."
2655         https://bugs.webkit.org/show_bug.cgi?id=171139
2656         http://trac.webkit.org/changeset/215634
2657
2658 2017-04-21  Commit Queue  <commit-queue@webkit.org>
2659
2660         Unreviewed, rolling out r215620 and r215623.
2661         https://bugs.webkit.org/show_bug.cgi?id=171139
2662
2663         broke arm64 build (Requested by keith_miller on #webkit).
2664
2665         Reverted changesets:
2666
2667         "Add signaling API"
2668         https://bugs.webkit.org/show_bug.cgi?id=170976
2669         http://trac.webkit.org/changeset/215620
2670
2671         "Unreviewed, fix Cloop build."
2672         http://trac.webkit.org/changeset/215623
2673
2674 2017-04-21  Keith Miller  <keith_miller@apple.com>
2675
2676         Remove LL/SC from Atomics
2677         https://bugs.webkit.org/show_bug.cgi?id=171141
2678
2679         Reviewed by Saam Barati.
2680
2681         Adding load link and store conditionally was not an actual progression
2682         and the existing code is causing problems for users of Atomics. So let's
2683         get rid of it.
2684
2685         * heap/LargeAllocation.h:
2686         (JSC::LargeAllocation::testAndSetMarked):
2687         * heap/MarkedBlock.h:
2688         (JSC::MarkedBlock::testAndSetMarked):
2689         * heap/SlotVisitor.cpp:
2690         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
2691
2692 2017-04-21  Keith Miller  <keith_miller@apple.com>
2693
2694         Unreviewed, fix Cloop build.
2695
2696         * jit/ExecutableAllocator.h:
2697         (JSC::isJITPC):
2698
2699 2017-04-20  Keith Miller  <keith_miller@apple.com>
2700
2701         Add signaling API
2702         https://bugs.webkit.org/show_bug.cgi?id=170976
2703
2704         Reviewed by Filip Pizlo.
2705
2706         Update various uses of sigaction to use the new signaling API.
2707         Also switch VMTraps to use the thread message system instead of
2708         rolling it's own.
2709
2710         * jit/ExecutableAllocator.h:
2711         (JSC::isJITPC):
2712         * runtime/VMTraps.cpp:
2713         (JSC::installSignalHandler):
2714         (JSC::VMTraps::VMTraps):
2715         (JSC::VMTraps::SignalSender::send):
2716         (JSC::handleSigusr1): Deleted.
2717         (JSC::handleSigtrap): Deleted.
2718         (JSC::installSignalHandlers): Deleted.
2719         * runtime/VMTraps.h:
2720         * tools/SigillCrashAnalyzer.cpp:
2721         (JSC::installCrashHandler):
2722         (JSC::handleCrash): Deleted.
2723         * wasm/WasmFaultSignalHandler.cpp:
2724         (JSC::Wasm::trapHandler):
2725         (JSC::Wasm::enableFastMemory):
2726
2727 2017-04-21  Michael Saboff  <msaboff@apple.com>
2728
2729         X86-64 Assembler doesn't handle xchg with byte register src
2730         https://bugs.webkit.org/show_bug.cgi?id=171118
2731
2732         Reviewed by Saam Barati.
2733
2734         * assembler/X86Assembler.h:
2735         (JSC::X86Assembler::xchgb_rm): Use oneByteOp8() since these are 8 bit opcodes.
2736
2737 2017-04-21  Andy VanWagoner  <thetalecrafter@gmail.com>
2738
2739         [INTL] Implement Intl.DateTimeFormat.prototype.formatToParts
2740         https://bugs.webkit.org/show_bug.cgi?id=169458
2741
2742         Reviewed by JF Bastien.
2743
2744         Use udat_formatForFields to iterate through the parts of a formatted date string.
2745         Make formatToParts and related functions dependent on ICU version >= 55.
2746
2747         * icu/unicode/udat.h: Update to 55.1.
2748         * icu/unicode/ufieldpositer.h: Added from 55.1.
2749         * icu/unicode/uvernum.h: Update to 55.1
2750         * runtime/IntlDateTimeFormat.cpp:
2751         (JSC::IntlDateTimeFormat::partTypeString): Convert UDateFormatField to string.
2752         (JSC::IntlDateTimeFormat::formatToParts): Return parts of formatted date string.
2753         * runtime/IntlDateTimeFormat.h:
2754         * runtime/IntlDateTimeFormatPrototype.cpp:
2755         (JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): Add prototype function formatToParts.
2756
2757 2017-04-20  Konstantin Tokarev  <annulen@yandex.ru>
2758
2759         [cmake] Define FORWARDING_HEADERS_DIR in WebKitFS and use it everywhere
2760         https://bugs.webkit.org/show_bug.cgi?id=171071
2761
2762         Reviewed by Michael Catanzaro.
2763
2764         "${DERIVED_SOURCES_DIR}/ForwardingHeaders" path occurs very often in the
2765         build system files. GTK-specifc FORWARDING_HEADERS_DIR variable should
2766         be available for all ports.
2767
2768         * CMakeLists.txt:
2769         * PlatformWin.cmake:
2770
2771 2017-04-20  Konstantin Tokarev  <annulen@yandex.ru>
2772
2773         Remove unused lamda captures
2774         https://bugs.webkit.org/show_bug.cgi?id=171098
2775
2776         Reviewed by Yusuke Suzuki.
2777
2778         * bytecompiler/NodesCodegen.cpp:
2779         (JSC::ArrayNode::emitBytecode):
2780         * ftl/FTLState.cpp:
2781         (JSC::FTL::State::State):
2782         * wasm/WasmB3IRGenerator.cpp:
2783
2784 2017-04-20  Yusuke Suzuki  <utatane.tea@gmail.com>
2785
2786         [JSC][FTL] FTL should support Arrayify
2787         https://bugs.webkit.org/show_bug.cgi?id=169596
2788
2789         Reviewed by Saam Barati.
2790
2791         This patch simply expands the coverage of FTL by supporting Arrayify.
2792         While ArrayifyToStructure is already supported, Arrayify is not supported
2793         in FTL. While supporting Arrayify in FTL itself does not offer so much
2794         performance difference from DFG's one, no FTL support for Arrayify
2795         prevents us applying FTL to the code including Arrayify.
2796
2797         * dfg/DFGArrayMode.cpp:
2798         (JSC::DFG::toIndexingShape):
2799         * dfg/DFGSpeculativeJIT.cpp:
2800         (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
2801         * ftl/FTLCapabilities.cpp:
2802         (JSC::FTL::canCompile):
2803         * ftl/FTLLowerDFGToB3.cpp:
2804         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2805         (JSC::FTL::DFG::LowerDFGToB3::compileArrayify):
2806         (JSC::FTL::DFG::LowerDFGToB3::compileCheckArray):
2807         (JSC::FTL::DFG::LowerDFGToB3::isArrayTypeForArrayify):
2808         (JSC::FTL::DFG::LowerDFGToB3::isArrayTypeForCheckArray):
2809         (JSC::FTL::DFG::LowerDFGToB3::compileArrayifyToStructure): Deleted.
2810         (JSC::FTL::DFG::LowerDFGToB3::isArrayType): Deleted.
2811
2812 2017-04-20  Mark Lam  <mark.lam@apple.com>
2813
2814         virtualThunkFor() needs to materialize its of tagMaskRegister for tail calls.
2815         https://bugs.webkit.org/show_bug.cgi?id=171079
2816         <rdar://problem/31684756>
2817
2818         Reviewed by Saam Barati.
2819
2820         This is needed because tail calls would restore callee saved registers (and
2821         therefore, potentially clobber the tag registers) before jumping to the thunk.
2822
2823         * jit/ThunkGenerators.cpp:
2824         (JSC::virtualThunkFor):
2825
2826 2017-04-20  Mark Lam  <mark.lam@apple.com>
2827
2828         Build fix after r215592.
2829         https://bugs.webkit.org/show_bug.cgi?id=171088
2830
2831         Not reviewed.
2832
2833         * assembler/MacroAssemblerPrinter.h:
2834
2835 2017-04-20  Mark Lam  <mark.lam@apple.com>
2836
2837         Update the MASM probe to only take 1 arg instead of 2 (in addition to the callback function).
2838         https://bugs.webkit.org/show_bug.cgi?id=171088
2839
2840         Reviewed by Michael Saboff and Saam Barati.
2841
2842         Experience shows that we never use the 2nd arg.  So, let's remove it to reduce
2843         the footprint at each probe site.
2844
2845         Also fix the MacroAssembler::print() function so that it is a no-op when
2846         !ENABLE(MASM_PROBE).  This will allow us to have print() statements in JIT code
2847         without a lot of #if ENABLE(MASM_PROBE)s later.
2848
2849         * assembler/AbstractMacroAssembler.h:
2850         * assembler/MacroAssembler.cpp:
2851         (JSC::stdFunctionCallback):
2852         (JSC::MacroAssembler::probe):
2853         * assembler/MacroAssembler.h:
2854         * assembler/MacroAssemblerARM.cpp:
2855         (JSC::MacroAssemblerARM::probe):
2856         * assembler/MacroAssemblerARM.h:
2857         * assembler/MacroAssemblerARM64.cpp:
2858         (JSC::MacroAssemblerARM64::probe):
2859         * assembler/MacroAssemblerARM64.h:
2860         * assembler/MacroAssemblerARMv7.cpp:
2861         (JSC::MacroAssemblerARMv7::probe):
2862         * assembler/MacroAssemblerARMv7.h:
2863         * assembler/MacroAssemblerPrinter.cpp:
2864         (JSC::MacroAssemblerPrinter::printCallback):
2865         * assembler/MacroAssemblerPrinter.h:
2866         (JSC::MacroAssemblerPrinter::print):
2867         (JSC::MacroAssembler::print):
2868         * assembler/MacroAssemblerX86Common.cpp:
2869         (JSC::MacroAssemblerX86Common::probe):
2870         * assembler/MacroAssemblerX86Common.h:
2871
2872 2017-04-20  Matt Baker  <mattbaker@apple.com>
2873
2874         Web Inspector: Add regular expression support to XHR breakpoints
2875         https://bugs.webkit.org/show_bug.cgi?id=170099
2876         <rdar://problem/31558082>
2877
2878         Reviewed by Joseph Pecoraro.
2879
2880         * inspector/protocol/DOMDebugger.json:
2881         New optional `isRegex` parameter denotes whether `url` contains
2882         a regular expression.
2883
2884 2017-04-15  Filip Pizlo  <fpizlo@apple.com>
2885
2886         Optimize SharedArrayBuffer in the DFG+FTL
2887         https://bugs.webkit.org/show_bug.cgi?id=164108
2888
2889         Reviewed by Saam Barati.
2890         
2891         This adds atomics intrinsics to the DFG and wires them through to the DFG and FTL backends. This
2892         was super easy in the FTL since B3 already has comprehensive atomic intrinsics, which are more
2893         powerful than what we need right now. In the DFG backend, I went with an easy-to-write
2894         implementation that just reduces everything to a weak CAS loop. It's very inefficient with
2895         registers (it needs ~8) but it's the DFG backend, so it's not obvious how much we care.
2896         
2897         To make the rare cases easy to handle, I refactored AtomicsObject.cpp so that the operations for
2898         the slow paths can share code with the native functions.
2899         
2900         This also fixes register handling in the X86 implementations of CAS, in the case that
2901         expectedAndResult is not %rax. This also fixes the ARM64 implementation of branchWeakCAS.
2902         
2903         I adapted the CascadeLock from WTF/benchmarks/ToyLocks.h as a microbenchmark of lock performance.
2904         This benchmark performs 2.5x faster, in both the contended and uncontended case, thanks to this
2905         change. It's still about 3x slower than native. I investigated this only a bit. I suspect that
2906         the story will be different in asm.js code, which will get constant-folding of the typed array
2907         backing store by virtue of how it uses lexically scoped variables as pointers to the heap arrays.
2908         It's worth noting that the native lock I was comparing against, the very nicely-tuned
2909         CascadeLock, is at the very high end of lock throughput under virtually all conditions
2910         (uncontended, microcontended, held for a long time). I also compared to WTF::Lock and others, and
2911         the only ones that performed better in this microbenchmark were spinlocks. I don't recommend
2912         using those. So, when I say this is 3x slower than native, I really mean that it's 3x slower than
2913         the fastest native lock that I have in my arsenal.
2914         
2915         Also worth noting is that I experimented with exposing Atomics.yield(), which uses sched_yield,
2916         as a way of testing if adding a yield loop to the JS cascadeLock would help. It does not help. I
2917         did not investigate why.
2918
2919         * assembler/AbstractMacroAssembler.h:
2920         (JSC::AbstractMacroAssembler::JumpList::append):
2921         * assembler/CPU.h:
2922         (JSC::is64Bit):
2923         (JSC::is32Bit):
2924         * b3/B3Common.h:
2925         (JSC::B3::is64Bit): Deleted.
2926         (JSC::B3::is32Bit): Deleted.
2927         * b3/B3LowerToAir.cpp:
2928         (JSC::B3::Air::LowerToAir::appendTrapping):
2929         (JSC::B3::Air::LowerToAir::appendCAS):
2930         (JSC::B3::Air::LowerToAir::appendGeneralAtomic):
2931         * dfg/DFGAbstractInterpreterInlines.h:
2932         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2933         * dfg/DFGByteCodeParser.cpp:
2934         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2935         * dfg/DFGClobberize.h:
2936         (JSC::DFG::clobberize):
2937         * dfg/DFGDoesGC.cpp:
2938         (JSC::DFG::doesGC):
2939         * dfg/DFGFixupPhase.cpp:
2940         (JSC::DFG::FixupPhase::fixupNode):
2941         * dfg/DFGNode.h:
2942         (JSC::DFG::Node::hasHeapPrediction):
2943         (JSC::DFG::Node::hasArrayMode):
2944         * dfg/DFGNodeType.h:
2945         (JSC::DFG::isAtomicsIntrinsic):
2946         (JSC::DFG::numExtraAtomicsArgs):
2947         * dfg/DFGPredictionPropagationPhase.cpp:
2948         * dfg/DFGSSALoweringPhase.cpp:
2949         (JSC::DFG::SSALoweringPhase::handleNode):
2950         * dfg/DFGSafeToExecute.h:
2951         (JSC::DFG::safeToExecute):
2952         * dfg/DFGSpeculativeJIT.cpp:
2953         (JSC::DFG::SpeculativeJIT::loadFromIntTypedArray):
2954         (JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult):
2955         (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
2956         (JSC::DFG::SpeculativeJIT::getIntTypedArrayStoreOperand):
2957         (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
2958         * dfg/DFGSpeculativeJIT.h:
2959         (JSC::DFG::SpeculativeJIT::callOperation):
2960         * dfg/DFGSpeculativeJIT32_64.cpp:
2961         (JSC::DFG::SpeculativeJIT::compile):
2962         * dfg/DFGSpeculativeJIT64.cpp:
2963         (JSC::DFG::SpeculativeJIT::compile):
2964         * ftl/FTLAbstractHeapRepository.cpp:
2965         (JSC::FTL::AbstractHeapRepository::decorateFencedAccess):
2966         (JSC::FTL::AbstractHeapRepository::computeRangesAndDecorateInstructions):
2967         * ftl/FTLAbstractHeapRepository.h:
2968         * ftl/FTLCapabilities.cpp:
2969         (JSC::FTL::canCompile):
2970         * ftl/FTLLowerDFGToB3.cpp:
2971         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2972         (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite):
2973         (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsIsLockFree):
2974         (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
2975         (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
2976         (JSC::FTL::DFG::LowerDFGToB3::pointerIntoTypedArray):
2977         (JSC::FTL::DFG::LowerDFGToB3::loadFromIntTypedArray):
2978         (JSC::FTL::DFG::LowerDFGToB3::storeType):
2979         (JSC::FTL::DFG::LowerDFGToB3::setIntTypedArrayLoadResult):
2980         (JSC::FTL::DFG::LowerDFGToB3::getIntTypedArrayStoreOperand):
2981         (JSC::FTL::DFG::LowerDFGToB3::vmCall):
2982         * ftl/FTLOutput.cpp:
2983         (JSC::FTL::Output::store):
2984         (JSC::FTL::Output::store32As8):
2985         (JSC::FTL::Output::store32As16):
2986         (JSC::FTL::Output::atomicXchgAdd):
2987         (JSC::FTL::Output::atomicXchgAnd):
2988         (JSC::FTL::Output::atomicXchgOr):
2989         (JSC::FTL::Output::atomicXchgSub):
2990         (JSC::FTL::Output::atomicXchgXor):
2991         (JSC::FTL::Output::atomicXchg):
2992         (JSC::FTL::Output::atomicStrongCAS):
2993         * ftl/FTLOutput.h:
2994         (JSC::FTL::Output::store32):
2995         (JSC::FTL::Output::store64):
2996         (JSC::FTL::Output::storePtr):
2997         (JSC::FTL::Output::storeFloat):
2998         (JSC::FTL::Output::storeDouble):
2999         * jit/JITOperations.h:
3000         * runtime/AtomicsObject.cpp:
3001         (JSC::atomicsFuncAdd):
3002         (JSC::atomicsFuncAnd):
3003         (JSC::atomicsFuncCompareExchange):
3004         (JSC::atomicsFuncExchange):
3005         (JSC::atomicsFuncIsLockFree):
3006         (JSC::atomicsFuncLoad):
3007         (JSC::atomicsFuncOr):
3008         (JSC::atomicsFuncStore):
3009         (JSC::atomicsFuncSub):
3010         (JSC::atomicsFuncWait):
3011         (JSC::atomicsFuncWake):
3012         (JSC::atomicsFuncXor):
3013         (JSC::operationAtomicsAdd):
3014         (JSC::operationAtomicsAnd):
3015         (JSC::operationAtomicsCompareExchange):
3016         (JSC::operationAtomicsExchange):
3017         (JSC::operationAtomicsIsLockFree):
3018         (JSC::operationAtomicsLoad):
3019         (JSC::operationAtomicsOr):
3020         (JSC::operationAtomicsStore):
3021         (JSC::operationAtomicsSub):
3022         (JSC::operationAtomicsXor):
3023         * runtime/AtomicsObject.h:
3024
3025 2017-04-19  Youenn Fablet  <youenn@apple.com>
3026
3027         [Mac] Allow customizing H264 encoder
3028         https://bugs.webkit.org/show_bug.cgi?id=170829
3029
3030         Reviewed by Alex Christensen.
3031
3032         * Configurations/FeatureDefines.xcconfig:
3033
3034 2017-04-19  Michael Saboff  <msaboff@apple.com>
3035
3036         Tune GC related JSC options for iOS
3037         https://bugs.webkit.org/show_bug.cgi?id=171019
3038
3039         Reviewed by Mark Lam.
3040
3041         Always set these GC options on iOS.
3042
3043         * runtime/Options.cpp:
3044         (JSC::overrideDefaults):
3045
3046 2017-04-19  JF Bastien  <jfbastien@apple.com>
3047
3048         WebAssembly: fast memory cleanups
3049         https://bugs.webkit.org/show_bug.cgi?id=170909
3050
3051         Reviewed by Saam Barati.
3052
3053         * b3/B3LowerToAir.cpp: correct comment, and make wasm-independent
3054         (JSC::B3::Air::LowerToAir::lower):
3055         * b3/B3Procedure.h:
3056         * b3/B3Validate.cpp:
3057         * b3/B3Value.cpp:
3058         (JSC::B3::Value::effects):
3059         * b3/B3WasmBoundsCheckValue.cpp: have the creator pass in a
3060         maximum, so we don't have to know so much about wasm here
3061         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
3062         (JSC::B3::WasmBoundsCheckValue::cloneImpl):
3063         (JSC::B3::WasmBoundsCheckValue::dumpMeta):
3064         * b3/B3WasmBoundsCheckValue.h:
3065         (JSC::B3::WasmBoundsCheckValue::boundsType):
3066         (JSC::B3::WasmBoundsCheckValue::bounds):
3067         * b3/air/AirCode.h:
3068         * b3/air/AirCustom.h:
3069         (JSC::B3::Air::WasmBoundsCheckCustom::generate):
3070         * b3/testb3.cpp:
3071         (JSC::B3::testWasmBoundsCheck):
3072         * wasm/WasmB3IRGenerator.cpp:
3073         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
3074         (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
3075         (JSC::Wasm::createJSToWasmWrapper): remove dead code
3076         * wasm/WasmMemory.cpp: don't GC if no memory could possibly be free'd
3077         (JSC::Wasm::Memory::initializePreallocations): verbose-only code,
3078         and copy-pasta bug
3079
3080 2017-04-19  Mark Lam  <mark.lam@apple.com>
3081
3082         B3StackmapSpecial should handle when stackmap values are not recoverable from a Def'ed arg.
3083         https://bugs.webkit.org/show_bug.cgi?id=170973
3084         <rdar://problem/30318657>
3085
3086         Reviewed by Filip Pizlo.
3087
3088         In the event of an arithmetic overflow on a binary sub instruction (where the
3089         result register is same as one of the operand registers), the CheckSub FTL
3090         operation will try to recover the original value in the clobbered result register.
3091
3092         This recover is done by adding the other operand value to the result register.
3093         However, this recovery method only works if the width of the original value in
3094         the result register is less or equal to the width of the expected result.  If the
3095         width of the original operand value (e.g. a JSInt32) is wider than the result
3096         (e.g. a machine Int32), then the sub operation would have zero extended the
3097         result and cleared the upper 32-bits of the result register.  Recovery by adding
3098         back the other operand will not restore the JSValue tag in the upper word.
3099
3100         This poses a problem if the stackmap value for the operand relies on that same
3101         clobbered register.
3102
3103         The fix is to detect this potential scenario (i.e. width of the Def's arg < width
3104         of a stackmap value).  If this condition is detected, we'll declare the stackmap
3105         value to be LateColdUse to ensure that the register allocator gives it a
3106         different register if needed so that it's not dependent on the clobbered register.
3107
3108         * b3/B3CheckSpecial.cpp:
3109         (JSC::B3::CheckSpecial::forEachArg):
3110         * b3/B3PatchpointSpecial.cpp:
3111         (JSC::B3::PatchpointSpecial::forEachArg):
3112         * b3/B3StackmapSpecial.cpp:
3113         (JSC::B3::StackmapSpecial::forEachArgImpl):
3114         * b3/B3StackmapSpecial.h:
3115
3116 2017-04-19  JF Bastien  <jfbastien@apple.com>
3117
3118         Unreviewed, rolling out r215520.
3119
3120         Broke Debian 8
3121
3122         Reverted changeset:
3123
3124         "[INTL] Implement Intl.DateTimeFormat.prototype.formatToParts"
3125         https://bugs.webkit.org/show_bug.cgi?id=169458
3126         http://trac.webkit.org/changeset/215520
3127
3128 2017-04-19  JF Bastien  <jfbastien@apple.com>
3129
3130         WebAssembly: limit slow memories
3131         https://bugs.webkit.org/show_bug.cgi?id=170825
3132
3133         Reviewed by Saam Barati.
3134
3135         We limits the number of fast memories, partly because ASLR. The
3136         code then falls back to slow memories. It first tries to virtually
3137         allocated any declared maximum (and in there, physically the
3138         initial), and if that fails it tries to physically allocate the
3139         initial without any extra.
3140
3141         This can still be used to cause a bunch of virtual
3142         allocation. This patch imposes soft limit on slow memories as
3143         well. The total virtual maximum for slow memories is set at the
3144         same (theoretical) value as that for fast memories.
3145
3146         Anything exceeding that limit causes allocation/grow to fail.
3147
3148         * wasm/WasmMemory.cpp:
3149
3150 2017-04-19  JF Bastien  <jfbastien@apple.com>
3151
3152         Cannot compile JavaScriptCore/runtime/VMTraps.cpp on FreeBSD because std::pair has a non-trivial copy constructor
3153         https://bugs.webkit.org/show_bug.cgi?id=170875
3154
3155         Reviewed by Mark Lam.
3156
3157         WTF::ExpectedDetail::ConstexprBase doesn't have a user-defined
3158         copy constructor, and its implicitly-defined copy constructor is
3159         deleted because the default std::pair implementation on FreeBSD
3160         has a non-trivial copy constructor. /usr/include/c++/v1/__config
3161         says _LIBCPP_TRIVIAL_PAIR_COPY_CTOR is disabled in order to keep
3162         ABI compatibility:
3163         https://svnweb.freebsd.org/changeset/base/261801.
3164
3165         That's a huge bummer, and I'm not a fan of broken stdlibs, but in
3166         this case it's pretty nice to have a custom named type anyways and
3167         costs nothing.
3168
3169         * runtime/VMTraps.cpp:
3170         (JSC::findActiveVMAndStackBounds):
3171         (JSC::handleSigusr1):
3172         (JSC::handleSigtrap):
3173
3174 2017-04-19  Andy VanWagoner  <thetalecrafter@gmail.com>
3175
3176         [INTL] Implement Intl.DateTimeFormat.prototype.formatToParts
3177         https://bugs.webkit.org/show_bug.cgi?id=169458
3178
3179         Reviewed by JF Bastien.
3180
3181         Use udat_formatForFields to iterate through the parts of a formatted date string.
3182
3183         * icu/unicode/udat.h: Update to 55.1.
3184         * icu/unicode/ufieldpositer.h: Added from 55.1.
3185         * runtime/IntlDateTimeFormat.cpp:
3186         (JSC::IntlDateTimeFormat::partTypeString): Convert UDateFormatField to string.
3187         (JSC::IntlDateTimeFormat::formatToParts): Return parts of formatted date string.
3188         * runtime/IntlDateTimeFormat.h:
3189         * runtime/IntlDateTimeFormatPrototype.cpp:
3190         (JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): Add prototype function formatToParts.
3191
3192 2017-04-19  JF Bastien  <jfbastien@apple.com>
3193
3194         WebAssembly: don't expose any WebAssembly JS object if JIT is off
3195         https://bugs.webkit.org/show_bug.cgi?id=170782
3196
3197         Reviewed by Saam Barati.
3198
3199         It's unexpected that we expose the global WebAssembly object if no
3200         JIT is present because it can't be used to compile or
3201         instantiate. Other APIs such as Memory should also be Inaccessible
3202         in those circumstances.
3203
3204         Also ensure that we don't pre-allocate fast memories if
3205         WebAssembly won't be used, and don't mark our intention to use a
3206         fast TLS slot for WebAssembly.
3207
3208         * runtime/Options.cpp:
3209         (JSC::recomputeDependentOptions):
3210
3211 2017-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
3212
3213         r211670 broke double to int conversion.
3214         https://bugs.webkit.org/show_bug.cgi?id=170961
3215
3216         Reviewed by Mark Lam.
3217
3218         In this patch, we take a template parameter way.
3219         While it reduces duplicate code, it effectively produces
3220         optimized code for operationToInt32SensibleSlow,
3221         and fixes kraken pbkdf2 regression on Linux.
3222
3223         And this patch also fixes undefined behavior by changing
3224         int32_t to uint32_t. If exp is 31, missingOne is 1 << 31,
3225         INT32_MIN. Thus missingOne - 1 will cause int32_t overflow,
3226         and it is an undefined behavior.
3227
3228         * runtime/MathCommon.cpp:
3229         (JSC::operationToInt32SensibleSlow):
3230         * runtime/MathCommon.h:
3231         (JSC::toInt32Internal):
3232         (JSC::toInt32):
3233
3234 2017-04-18  Mark Lam  <mark.lam@apple.com>
3235
3236         r211670 broke double to int conversion.
3237         https://bugs.webkit.org/show_bug.cgi?id=170961
3238         <rdar://problem/31687696>
3239
3240         Reviewed by Yusuke Suzuki.
3241
3242         This is because operationToInt32SensibleSlow() assumes that left shifts of greater
3243         than 31 bits on an 31-bit value will produce a 0.  However, the spec says that
3244         "if the value of the right operand is negative or is greater or equal to the
3245         number of bits in the promoted left operand, the behavior is undefined."
3246         See http://en.cppreference.com/w/cpp/language/operator_arithmetic#Bitwise_shift_operators.
3247
3248         This patch fixes this by restoring the check to prevent a shift of greater than
3249         31 bits.  It also consolidates the optimization in operationToInt32SensibleSlow()
3250         back into toInt32() so that we don't have 2 copies of the same code with only a
3251         slight variation.
3252
3253         JSC benchmarks shows that performance is neutral with this patch.
3254
3255         * dfg/DFGSpeculativeJIT.cpp:
3256         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
3257         * ftl/FTLLowerDFGToB3.cpp:
3258         (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
3259         * runtime/MathCommon.cpp:
3260         (JSC::operationToInt32SensibleSlow): Deleted.
3261         * runtime/MathCommon.h:
3262         (JSC::toInt32):
3263
3264 2017-04-18  Oleksandr Skachkov  <gskachkov@gmail.com>
3265
3266         [ES6]. Implement Annex B.3.3 function hoisting rules for eval
3267         https://bugs.webkit.org/show_bug.cgi?id=163208
3268
3269         Reviewed by Saam Barati.
3270
3271         Current patch implements Annex B.3.3 that is related to 
3272         hoisting of function declaration in eval. 
3273         https://tc39.github.io/ecma262/#sec-web-compat-evaldeclarationinstantiation
3274         Function declaration in eval should create variable with 
3275         function name in function scope where eval is invoked 
3276         or bind to variable if it declared outside of the eval. 
3277         If variable is created it can be removed by 'delete a;' command. 
3278         If eval is invoke in block scope that contains let/const 
3279         variable with the same name as function declaration 
3280         we do not bind. This patch leads to the following behavior: 
3281         '''
3282         function foo() {
3283            {
3284              print(boo); // undefined
3285              eval('{ function boo() {}}');
3286              print(boo); // function boo() {}
3287            }
3288            print(boo); // function boo() {}
3289         }
3290
3291         function foobar() {
3292           { 
3293             let boo = 10;
3294             print(boo); // 10;
3295             eval('{ function boo() {}}');
3296             print(boo); // 10;
3297           }
3298           print(boo) // 10
3299         }
3300
3301         function bar() {
3302            {
3303               var boo = 10;
3304               print(boo); // 10
3305               eval('{ function boo() {} }'); 
3306               print(boo); // function boo() {}
3307            }
3308            print(boo); // function boo() {}
3309         }       
3310         
3311         function bas() {
3312             {
3313                  let boo = 10;
3314                  eval(' { function boo() {} } ');
3315                  print(boo); // 10
3316             }
3317             print(boo); //Reference Error
3318         }
3319         '''
3320
3321         Current implementation relies on already implemented 
3322         'hoist function in sloppy mode' feature, with small changes.
3323         In short it works in following way: during hoisting of function 
3324         with name S in eval, we are looking for first scope that 
3325         contains space for variable with name S and if this scope 
3326         has var type we bind function there
3327
3328         To implement this feature was added bytecode ops:
3329         op_resolve_scope_for_hoisting_func_decl_in_eval - get variable scope 
3330         or return undefined if variable can't be binded there.
3331
3332         There is a corner case, hoist function in eval within catch block,
3333         that is not covered by this patch, and will be fixed in 
3334         https://bugs.webkit.org/show_bug.cgi?id=168184
3335
3336         * bytecode/BytecodeDumper.cpp:
3337         (JSC::BytecodeDumper<Block>::dumpBytecode):
3338         * bytecode/BytecodeList.json:
3339         * bytecode/BytecodeUseDef.h:
3340         (JSC::computeUsesForBytecodeOffset):
3341         (JSC::computeDefsForBytecodeOffset):
3342         * bytecode/CodeBlock.cpp:
3343         (JSC::CodeBlock::finalizeLLIntInlineCaches):
3344         * bytecode/EvalCodeBlock.h:
3345         (JSC::EvalCodeBlock::functionHoistingCandidate):
3346         (JSC::EvalCodeBlock::numFunctionHoistingCandidates):
3347         * bytecode/UnlinkedEvalCodeBlock.h:
3348         * bytecompiler/BytecodeGenerator.cpp:
3349         (JSC::BytecodeGenerator::BytecodeGenerator):
3350         (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
3351         (JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval):
3352         * bytecompiler/BytecodeGenerator.h:
3353         * dfg/DFGAbstractInterpreterInlines.h:
3354         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3355         * dfg/DFGByteCodeParser.cpp:
3356         (JSC::DFG::ByteCodeParser::parseBlock):
3357         * dfg/DFGCapabilities.cpp:
3358         (JSC::DFG::capabilityLevel):
3359         * dfg/DFGClobberize.h:
3360         (JSC::DFG::clobberize):
3361         * dfg/DFGDoesGC.cpp:
3362         (JSC::DFG::doesGC):
3363         * dfg/DFGFixupPhase.cpp:
3364         (JSC::DFG::FixupPhase::fixupNode):
3365         * dfg/DFGNode.h:
3366         (JSC::DFG::Node::hasIdentifier):
3367         * dfg/DFGNodeType.h:
3368         * dfg/DFGOperations.cpp: