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