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