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